Thoughts on Locking issues [resend]

["Robert S. Sfeir" <ro...@codepuccino.com>]

Hey guys,  (resending this from this AM since Brian said he didn't get it)

Real quick before I disappear for the day...

I was discussing some ideas about hot to handle optimistic locking in post
1.0 with Brian, and here are my thoughts on a couple of possible solutions.

First idea:

To handle locking correctly across all DBs we have to rely on our own
mechanism, and I think that the best way to do this would be to have our own
table which stores the object id and its serial id in that table.

On object select, you'd update that table with the ids of the returned
objects.  Now I know this can be a lot of overhead, so my suggestion is to
perhaps have something like a servlet running which can batch process the
ids after the select is done and data is returned to the user.  Something
that would happen in the background.  Chances are the user will not be fast
enough to update the objects to be affected by the small delay in updating
the ojb lock table.  This servlet could also be multithreaded but I don't
think it's necessary.

Second thought to this idea is that instead of just locking objects on
select, we can provide a method which does a special select, a
getObjectsForEdit(), where when this method is called, that's the time that
you update objects to the lock table.  This way when you do a 'normal'
select, you get the objects and nothing gets marked for lock, and we
minimize the overhead.

In either case, there should also be an option for automatic deprecation of
locks.  This should be something set by the user.  Say a user selects a
bunch of objects, if another user comes along and selects the objects and
updates them, we check with the table, if the last time these objects are >
then the pre determined timestamp, we override the lock, and allow the
update.  If it's less we give the engineer a choice to figure out what to
do.  These choices I think would be:
    1- Throw an error and tell the user object is already locked for edit
    2- Give them a method to try a gain without having to write too much
code, something like tryPersistAgain(numTimesToTry) so we can write a while
loop which would try to persist it the specified number of times, then fail
again.
    3- ignore lock completely and update, in which case we update our lock
table so the next user has the same choices.


Second idea, which I don't think is as reliable to code:

Do same as first but without tables, store objectid and serialid in a
Hashtable as objects get selected.  This will probably too memory intensive,
however we could have a process which removes objectids from the Hashtable
after a certain period of time so we can keep memory to a minimum.  I have
code which I used for cached table data in one of my apps which does this.
In my case it works great, but I don't know how much we can rely on it for
this purpose.
(removed code on resend... May be too long)

R



---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org