Re: Really unique session ID - PID + connection timestamp?

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

In response to

Responses

Browse pgsql-general by date

  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