On 04/10/2016 06:29 AM, durumdara@xxxxxxxxx wrote:
Dear Alban!
2016.04.10. 13:05 keltezéssel, Alban Hertroys írta:
On 10 Apr 2016, at 9:07, Durumdara <durumdara@xxxxxxxxx> wrote:
Dear Adrian!
Again. As I see the beginning blocks are removed by mailing system in
the code.
We have an "ourlocks" table which hold records (TableName, RecordID,
SessionInnerID, TimeStamp, etc, with TableName/RecordID prikey).
If anybody wants to lock record "for long time", "over the
transactions" it try to insert a new record here.
Why are those records being locked? Reading on, it seems like you're
trying to solve a fairly standard concurrency problem. Any RDBMS worth
their salt can handle that for you, you don't need to manually do any
of that.
This is not real locks. They are logical locks.
Products, offers are edited for long time.
Define long time, a session, a day, days, etc?
But we must save subdata. This is not a "word like document" which can
saved at once, in a transaction.
When a product edited, we must protect it from other user's edit.
But it's subdata must be posted/commited to the DB, for example
shipping, article quantity changes, vouchers, etc.
So folks can make changes to the attributes of a Product, Offer, etc
while it is being changed in ways they can not see?
Or do they get a read only view that changes as the 'locking' user makes
edits?
This sounds much more like a use-case for sub-transactions and select
for update (which puts a temporary RDBMS-controlled lock on the
relevant records) than for manual locking.
Yes, this is like sub-transaction.
But for only sub-data. The main data must be edited by only the first
user who started the edit.
This is a long time "lock" like thing. This what we simulate here.
Thanks for your suggestions. I will check this in our client library.
To be clear you are trying to come up with a solution that allows your
application to run against different databases(Firebird, SQL Server,
Postgres, etc?), using a single code base, correct?
dd
--
Adrian Klaver
adrian.klaver@xxxxxxxxxxx
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
