> Right. This is where you have to use a "soft lock". For example maintain a
> counter or timestamp on the corresponding database row, and check for
> collisions on update. Tons of stuff in the archives on this.
That is what I refer to as dirty checking, which I don't to synchronize
across VMS, more on why below.
> I think we have a terminology collision here. I equated dirty checking and
> optimistic locking...
I am using dirty checking with optimistic locking. Optimistic locking
assumes that concurrent updates will not happen, but if they do you
bette check them. Pessimistic locking prevents them from happening.
> The shared cache is a convenience and a performance booster. If we update a
> cached object on one machine, changes are propogated to other machines as
> required. This way we don't have the potential that the remote machine has a
> stale view of the cache. The next time a transaction involves the updated
> object on the remote machine, the new state is already there...
Here is why I decided to not do distributed cache on top of RDBMS (at
least not by default).
The distributed cache only works when all your access to a table is done
through the CMP layer, or whatever other API you give. Once a session
bean, JMS message, plain JDBC in a Servlet or some cron job does an
update to the database all is gone.
Once you start with the simple assumption that anything can happen and
that your commits can fail (!), you limit optimistic locking mode to the
cases where concurrent access is a low possibility. Low possibility
means almost zero gain in replicating these changes or distributing the
locks.
If you do need the locking guarantee then only optimistic locking (i.e.
SELECT FOR UPDATE) works, in which case the cache is totally redundant
(I just use it for object rollback). So no need to synchronize either.
Obviously you guys have put a lot of brain power into this, and
certainly an application that only accesses the database through this
API will benefit from distributed locking and caching. But such an
application must be designed with these assumptions in mind. They don't
go against the spirit of EJB, but they are certainly not portable to
other environments.
arkin
>
> > arkin
> >
> >
> >
> > >
> > > "There are a hundred ways to skin the cat". Hopefully I have not
> > offended
> > > any cat lovers today... No particular approach is 100% correct, it's a
> > > question of best fit for particular requirements.
> > >
> > > Regards,
> > >
> > > -Chris.
> >
> > --
> > ----------------------------------------------------------------------
> > Assaf Arkin www.exoffice.com
> > CTO, Exoffice Technologies, Inc. www.exolab.org
> >
> > ==========================================================================
> > =
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> > body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
--
----------------------------------------------------------------------
Assaf Arkin www.exoffice.com
CTO, Exoffice Technologies, Inc. www.exolab.org
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
