Hi

i have one critical problem. i have one source code which has
db.eq(table, db.lock) added after every db.insert (tablename,db.retry)

what is significance of this ? in my opinion using db.eq we can avoid db.retry.point() and we can commit in the end

can any one throw some light on this ?

also tell me whether it has any bearing on performance of the session and locking of that table for all other sessions which will be using that table for inserting new records

When you use db.eq(table, db.lock), you are locking the record at that point. It is locked for all other applications trying to access the record, and does not unlock until you issue a commit or abort.

When you use the select statement to lock the record (select... from table for update), you are using a delayed lock. This means that the record will not be locked until the actual point of update - the commit. It's only locked for a milisecond or so, while the update occurs. For this reason, it is possible to have "dirty reads", where the record has changed since it was last read. That's what the retry point is for. You use the db.retry.point() above the select for update. When you update using db.insert or db.update, use the db.retry option. When the commit happens, it sees if there is any change since the read, and will go back (rollback) to the retry point and start all over if so.

The db.retry is more complicated to use, but avoids long table locks.

There is no reason to lock when doing inserts, only updates or deletions. When inserting, you should be checking to make sure you are not inserting a duplicate record, but that does not involve locking.

Also, you will need the commit, whether you use the db.lock or the delayed lock method of locking, or no locking at all. The commit sends any updates to the database, and nothing really happens without it.

For those who got confused when editing, reading the current thread. I have split off the 2nd question into a separate thread! (http://www.baanboard.com/baanboard/showthread.php?s=&threadid=757)