Assaf,
Here we go again ;-)
Assaf said:
> -----Original Message-----
> Chris Raber wrote:
> >
> > Assaf,
> >
> > I'll address the alternative approach you outlined in your other post in
> > detail (time allowing). In short, database locks are only good for the
> time
> > span for which we hold onto a database connection. In the world of
> > datasource connection pooling, locks are are usually only good within
> short
> > transaction boundaries. To handle concurrency detection for a short
> > transaction model (where the user is outide transaction during think
> time),
> > soft locking is required (e.g. by using timestamps, counters, state
> > comparisons...). I assume this is what you mean by "dirty checking".
>
> This has nothing to do with connection pooling, you can hold onto a
> connection for as long as you hold onto the transaction, and you can
> hold onto the transaction (and connection) across multiple invocations
> on a stateful session beans. (Not that I recommend that anyone do that).
>
Yes of course. I was refering to the result of holding onto the transaction,
i.e. that the connection would be held on to. We are in violent agreement.
> So the question is how do you perform updates in memory not within a
> database transactions. I have the code to do that, but I couldn't find
> anything in the EJB or ODMG API that allows me to do that. Once you're
> outside the context of a transaction, how do you lock the objects.
>
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.
> I can easily add an API for that, but as long as it's not industry
> standard, I'm going to stay clear of that.
>
It would be nice if the technical services layer of the architecture handles
this for you. In our Developer's Guide, the OR mapping layer has this built
in... As you say it is "non-standard", but it's not proprietary GS/J code
either. Just a bunch of Java code that anyone could use for OR mapping...
> > An issue I see with dirty checking as you have suggested it is that
> every
> > time we want to read from cache we have to also read from the datasource
> of
> > record to check cache coherency. The cost of the coherency check largely
>
> No. Dirty checking works at store time, it's optimistic locking model.
>
I think we have a terminology collision here. I equated dirty checking and
optimistic locking...
> If you want to make sure your object is synchronized before starting to
> work with it, forget about soft transactions. Work with your EJB in the
> context of a transaction, specify exclusive access, and dirty checking
> will never happen.
>
> If you are performing operations outside of transaction boundary,
> there's no alternative to dirty checking.
>
Yup.
> I know there are solutions in between these two extremes, but they don't
> yield easily to a CMP model.
>
I haven't thought about it in a CMP context yet. I'd be interested to know
how current CMP implementations handle optimistic concurrency and buffered
updates from outside transaction.
>>> snip some arguments about caching... I'm getting tired.
> But all of these arguments don't explain to me why you need a shared
> cache. I don't see where the shared cache comes into play, and I don't
> where it gives you any transactional assurance. You can prevent two
> servers form affecting the same bean, but you cannot avoid the database
> being updated concurrently.
>
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...
> 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".
