Chris;
I am jumping in mid-discussion so please bear with me
if you have addressed this.
I am interested in keeping an in memory cache, but my
concern, which you may have resolved, is what happens
when unpersisted (DBMS) transactions are sitting in
cache and there is a system failure ? Is your
architecture simply transaction loss tolerant, or are
you persisting your in cache changes somewhere other
than the database ? If so, is this persistence model
speedier than the DBMS ?
//Nicholas
--- Chris Raber <[EMAIL PROTECTED]> wrote:
> 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".
>
>
=====
"Suzie, Suzie, Suzie, Suzie
Suzie, Suzie Greenberg"
Suzie Greenberg, Phish
--
Nicholas Whitehead
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
===========================================================================
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".
