Ralf Schneider wrote:
> has anyone experiences with locking database records on an
> application level?
>
> My problem:
> I develop a client application on Linux. There might be
> several instances in
> the network that access the same database. If a user opens
> one data item
> (several records in different tables) for editing the data,
> this item should
> be locked so that the next user that wants to edit this item
> gets an error
> message.
>
> I have two ideas for solving this problem: One is on database
> level using
> locks and the other is on application level using a column
> where I enter the
> username who locked the item.
>
> One problem is: What happens if the client application
> crashes and the lock
> is not removed? For the application level locking a possible
> solution would
> be to setup a cron job that regularly checks if the usernames
> in the locked
> records are in the table CONNECTEDUSERS yet.
>
> Any comments?
1. If one only checks the username and not the sessionno it will not
work correctly if
* two people uses the same database-username
* the one guy whose connection helds the lock connected again in the
meantime
without locking the same item again (and releasing it in the end)
2. If one updates one column in the item itself, others will have some
trouble
when they try to read it (except in isolation level 0). They will wait
for the
end of the transaction holding the write-lock. updaters will wait, too.
Only if NOWAIT is used together with explicit LOCK or SELECT the
error is returned immediately.
3. If the application does an insert in a special LOCK-table and the working
with the item in ONE transaction, then a crash of the application will
rollback
all the work. No 'lock' is left.
Elke
SAP Labs Berlin
_______________________________________________
sapdb.general mailing list
[EMAIL PROTECTED]
http://listserv.sap.com/mailman/listinfo/sapdb.general
