From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | "durumdara(at)gmail(dot)com" <durumdara(at)gmail(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Really unique session ID - PID + connection timestamp? |
Date: | 2016-04-10 16:03:10 |
Message-ID: | 570A793E.7080506@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 04/10/2016 06:29 AM, durumdara(at)gmail(dot)com wrote:
>
> Dear Alban!
>
>
> 2016.04.10. 13:05 keltezéssel, Alban Hertroys írta:
>>> On 10 Apr 2016, at 9:07, Durumdara <durumdara(at)gmail(dot)com> 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(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2016-04-10 16:24:33 | Re: Bypassing NULL elements in row_to_json function |
Previous Message | Adrian Klaver | 2016-04-10 15:56:02 | Re: Bypassing NULL elements in row_to_json function |