At 11:48 AM 24-05-02 +0300, you wrote:

> >
> > Pessimistic locking is not generally seen as "C/S architecture". Not
> > that I am certain I agree with the philosophy. The flag field
> > arrangement is just a way to force pessimistic locking capability past
> > a system not designed to support it.
> >
>
>You are absolutely right. I mean ; if I were using C/S architecture I should
>have a better way other than pessimistic locking. How do you solve this kind
>of problem in your applications ?

I think you need to turn your thinking around another way and escape from
the "desktop model" of multi-user interactive use. A pessimistic locking
system supposes that, in the (usually unlikely) event that two users will
be trying to edit the same record(s) concurrently, the second user will be
prevented from going into Edit mode if the first user is already
editing. What it does is to assume that the user will actually change
something.

An optimistic locking system doesn't rely on row-level locks to deny user
update-access to the record. It allows both to enter into a transaction
with the same data; then, the first user to request an update will
succeed. Depending on the parameters of the second user's transaction, the
second request will be allowed or denied once the first request is committed.

The IBO "pessimistic lock" pushes forward the moment when user1 obtains the
lock, by posting a dummy update to the server. Although this dummy update
does not change any data, the server does not know that, and will block any
other attempt to get the same lock, i.e. user2 will be prevented from going
into edit mode (from the client perspective) because her request for the
dummy update is denied.

So, if IBO pessimistic locking is used, there is no condition where two
users have edits competing to update the same record, since the first
user's dummy update denies all other users' requests to perform the same
dummy update. IBO will detect this condition and refuse to let that row be
edited. This is a reasonable technique for dealing with conditions which
would otherwise lock up the system with constant deadlocks.

The "pessimistic lock" overrules normal client/server behaviour, which is
to restrict no users but to isolate each unit of work in its own
transaction context. The client/server model does not presume that any
user will update any row. During the course of a transaction, should a
user request an update of any item of data in his/her transaction, it is
presumed to be allowed unless there is a data integrity violation. A good
update will be denied if and only if another user already has made a
successful update request pertaining to the same row.

The real-world situation for multi-user interactive editing is that it will
be rare for two users to be editing the same record concurrently. If it
should happen that they do, it is more than probable that there is an error
in office procedures and we WANT to kill all attempts except one. In this
case, we don't want pessimistic locking, since PL will only delay the
misdeed of duplicating or overwriting work.

We want to alert the users that they are stepping on each other's toes, and
ensure that only one data status is current for a record at any given
moment. That is why you should regard a deadlock as a friendly condition,
not one to avoid. A deadlock is a safeguard that signals when something is
wrong with the work-flow. Infrequent deadlocks are OK.

So, really, you shouldn't use pessimistic locking unless you have a
requirement to let different users change the status of the *same* data in
rapid order. This is a better way to handle poorly-analysed workflow than
persistent deadlocking. If you can justify the workflow (and sometimes you
can) then you can justify the pessimistic lock.

regards,
Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at
www.ibobjects.com