On-line docs http://download-west.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_lock.htm
DA Morgan's docs http://www.psoug.org/reference/dbms_lock.html On Tue, Jun 23, 2009 at 12:58 AM, Maarten Bosteels<mbosteels....@gmail.com> wrote: > Hi, > > We have implemented something similar. In our case multiple applications > should be able to request locks, so we have implemented it on the database. > It's based on DBMS_LOCK (Oracle specific). > When an application crashes (or is killed in an unclean manner) Oracle will > roll back any pending transactions, and automagically release the locks. > Works very well (btw, our applications never crash :-) > > Since you have only one application, I guess you could do it in the > application layer (keep locks in memory). > > Maarten > > > On Tue, Jun 23, 2009 at 3:07 AM, James Carman > <jcar...@carmanconsulting.com>wrote: > >> If it's fairly unlikely that two people would be editing the same record at >> the same time, then it's probably okay to go with optimistic locking. >> >> On Mon, Jun 22, 2009 at 8:41 PM, satar <starl...@gmail.com> wrote: >> >> > >> > Yep, that is what I thought from the reading I have done. I think I will >> do >> > it the way I have in the past but using an application-level edit table >> > instead of having to use a database. This feels more natural to me and I >> > have spent an absorbent amount of time learning Hibernate already and >> just >> > hoping that I get some return from all of the complexities it has >> > eventually. I do believe that will be the case because all you smart >> peeps >> > wouldn't be using it if there was nothing to gain. The dirty read problem >> > seems like such a normal condition for any application that has multiple >> > writers, so I thought I would see what is a typical approach within web >> > apps >> > -- something I am very new at. >> > -- >> > View this message in context: >> > http://www.nabble.com/Dirty-read-edit-problem.-tp24157057p24158076.html >> > Sent from the Wicket - User mailing list archive at Nabble.com. >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > For additional commands, e-mail: users-h...@wicket.apache.org >> > >> > >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
