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?
|
Список | 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 по дате отправления: