Re: Delphi 2005, Postgresql, ZEOS & optimistic locking - Mailing list pgsql-general

From Ralf Schuchardt
Subject Re: Delphi 2005, Postgresql, ZEOS & optimistic locking
Date
Msg-id 20050512211235.3a26dc0d@lord.homenet
Whole thread Raw
In response to Re: Delphi 2005, Postgresql, ZEOS & optimistic locking  ("Philippe Lang" <philippe.lang@attiksystem.ch>)
List pgsql-general
Hi!

On Thu, 12 May 2005 19:19:10 +0200
"Philippe Lang" <philippe.lang@attiksystem.ch> wrote:

> Thanks for your answer, but I'm not sure we are talking about the
> same thing. What I was used to with MS Access/ODBC/Postgresql, in a
multiuser network scenario, is the following:
>
> - User A loads data in a form
> - User B loads the same data in a form.
> - Before user A makes changes, B makes his changes, and commits them.
> - User A makes changes, and tries to commit them, but... the software
> shouts, because meanwhile, someone else made changes to the data
> loaded in the form.
>
> That's what I call optimistic locking.
[...]
> Is there a way to do the same with ZEOS? Or maybe is there another
> mecanism that could be used to do optimistic locking? Some kind of
> "long transactions", in the database server?

You  could include the old values of columns which could change in the
where clause of your update statement. For example:

UPDATE mytable SET col1 = 'newValue'
WHERE col1 = 'oldValue1' AND col2 = 'oldValue2';

This way, whenever a row has changed (col1 or col2 have different
values), this update will fail (i.e. no row gets updated).


Ralf Schuchardt

> Hi Philippe,
>
> It still works the same way as the ODBC driver, because of
> Postgresql's multi version concurrency. Zeos uses libpq exactly like
> the ODBC driver does, except it talks directly to libpq without the
> overhead of ODBC, and all you have to deploy with your app is the
> super small libpq.dll.
>
> You really never have to worry about locks.
> However if you want to do a bunch of commands in the context of a
> long transaction you need to pick one of the isolation levels like
> read commited and then in your code do something like this:
>
>                  with myconnection do
>                       begin
>             Myconnection.connection.StartTransaction;
>                         try
>                                 sql.add('insert into
> sometable (field1) VALUES ('bla')'); execsql;
>                                  //do some more operations in the
> same transaction sql.clear;
>                                  sql.add('select * from sometable');
>                 open;
>
>                 Myconnection.commit;
>                        except
>                 //if a error occurs rollback
> everything we did in the transaction Myconnection.connection.Rollback;
>                        end;
>              end;
>
>
> When ever I use Zeos I always set the isolation level to tiNone and
> let the server handle the transactions. When you use tiNone you
> simply do all your statements in one operation, just do a bunch of
> adds and seperate each statement with a semi colon, then do the
> execsql.  All the statements will be executed in a single transaction
> by the server and if a error occurs they all get rolled back.
>
> Hope this helps you out.
>
> --
> Tony Caduto
> AM Software Design
> Home of PG Lightning Admin for Postgresql 8.x
> http://www.amsoftwaredesign.com

> Philippe Lang wrote:
> > Hi,
> >
> > I've been testing Delphi 2005 with Postgresql 7.4.5, through ZEOS
> > Lib 6.5.1, and I have a question:
> >
> > How do you implement an optimistic locking strategy with these
> > tools? With an Access front-end, and the ODBC driver, this is
> > completely transparent. A test showed me that the Delphi client
> > writes to the database without worrying about another user doing
> > that meanwhile...
> >
> > I saw it's possible to manipulate the isolation level (read
> > commited or serializable only) in the ZEOS controls, but it does
> > not help at all here. An optimistic lock is a kind of "long
> > transaction" for me.
> >
> > Thanks for your time!
> >
> > Philippe

pgsql-general by date:

Previous
From: "Jimmie H. Apsey"
Date:
Subject: Re: pg_dump fails on 7.4 Postgres
Next
From: "Reid Thompson"
Date:
Subject: Re: pg_dump: ERROR: Memory exhausted in AllocSetAlloc(875574064)