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

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: Really unique session ID - PID + connection timestamp?
Дата
Msg-id 570A793E.7080506@aklaver.com
обсуждение исходный текст
Ответ на Re: Really unique session ID - PID + connection timestamp?  ("durumdara@gmail.com" <durumdara@gmail.com>)
Ответы Re: Really unique session ID - PID + connection timestamp?  (Durumdara <durumdara@gmail.com>)
Список pgsql-general
On 04/10/2016 06:29 AM, durumdara@gmail.com wrote:
>
> Dear Alban!
>
>
> 2016.04.10. 13:05 keltezéssel, Alban Hertroys írta:
>>> On 10 Apr 2016, at 9:07, Durumdara <durumdara@gmail.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.klaver@aklaver.com


В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: Bypassing NULL elements in row_to_json function
Следующее
От: "David G. Johnston"
Дата:
Сообщение: Re: Bypassing NULL elements in row_to_json function