Simone,
really, this is not a cache decision, AT ALL. The state synchronization is
the state synchronization with the DB, it is a different domain. The cache
should not, does not, will not take state synchronization decisions with
respect to the database. It is a store with passivation policies. It will
decide about its passivation policies, i.e. it's memory management, but
certainly not how to refresh the state from db and to answer a question you
posed earlier, no, the state sync and the LRU algo are not the same.
Finally (between us) let's try to focus on that one-thread busy wait problem
(the one that gives the LOCKING WAITING) I took privately with you yesterday
before we make this piece of code unecessarily complicated ;-)
In clear let's fix the problems with the current cache before we touch the
other interceptors yeah?
sorry to be violent, it is just that in *every* interceptor I have looked at
there is tons of work to be done, sometimes to make it just work.
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of
|Bordet, Simone
|Sent: Friday, May 11, 2001 11:53 AM
|To: '[EMAIL PROTECTED]'
|Subject: RE: [JBoss-dev] RE: Option D - Take One !
|
|
|Hey Vinay
|
|> Hi Simon.
|> Thanks for the response. I must admit that I have really
|> not dug deep
|> into the guts of quite a few classes in JBoss. Why I put it
|> in a separate
|> Interceptor is
|>
|> 1. Does not become part of standard jboss release if we go for spec
|> compliance and stuff!
|
|Same for the cache policy solution: standardjboss.xml by default does not
|have this option D cache policy, as well as it would not have your
|interceptor.
|
|> 2. Users can add and remove it as required from the jboss.xml
|> so that they
|> have more control over it.
|
|The same for the new cache policy.
|
|> 3. Code does not really touch any other code classes [except for the
|> metadata bit]
|
|Same as above ;)
|
|OTOH when you want to have commit D you must have this interceptor and it
|brings a (little) overhead on every call, while with the cache policy
|solution you have a (brief) cache freeze for that bean when the timer task
|is invalidating the contexts (you have to be unlucky to see things slow
|down). Another small consideration can be that probably the cache policy
|solution will require less coding. Another thing is that if you extend this
|option D to invalidate the cache on demand (for example through a JMS
|message), you can do that in a simpler way that with the interceptor, since
|you are inside the cache code.
|I don't see a *very* strong argument in favor of one or the other, do you
|have other thoughts ?
|
|Simon
|
|>
|>
|> Vinay
|> ----- Original Message -----
|> From: "Bordet, Simone" <[EMAIL PROTECTED]>
|> To: "JBoss Development Mailing List (E-mail)"
|> <[EMAIL PROTECTED]>
|> Sent: Friday, May 11, 2001 4:18 PM
|> Subject: [JBoss-dev] RE: Option D - Take One !
|>
|>
|> > Hey Vinay,
|> >
|> > [please plain text email]
|> >
|> > > Hello Folks,
|> > > Took a wild shot at the Option D, timed cache invalidation.
|> > > Have put it in a separate interceptor that sits before the
|> > > EntitySynchronizationInterceptor and invalidates the
|> > > EntityEnterpriseContext at regular preset intervals.
|> >
|> > I would have written a simple TimerTask in a LRU cache
|> policy, as I've
|> done
|> > for the stateful bean removal.
|> > The issues (entity beans invalidation and stateful beans
|> removal) are very
|> > similar, aren't they ?
|> >
|> > > 1. There is an invalidation timer task per entity bean [I
|> > > persum per-EntityEnterpriseContext maps to per bean and not
|> > > per bean instance]
|> >
|> > I saw you use java.util.TimerTask.
|> > I reimplemented them because in the early days we wanted to
|> be compatible
|> > with jdk1.2.2, and these classes were added only in JDK
|> 1.3. I don't know
|> if
|> > this constraint is still there (running the server in a
|> 1.2.2 JVM) but...
|> >
|> > > 2. The refersh rate is currently set at 60secs but could be
|> > > moved elsewhere to the jboss config xml
|> >
|> > OK
|> >
|> > > 3. The Configuration Metadat now has an entry for option D.
|> >
|> > OK
|> >
|> > > 4. The interceptor does NOT reload the entity. It just
|> > > invalidates the cache. The entity reload is managed by the
|> > > EntitySynchronizationInterceptor.
|> >
|> > YES
|> >
|> > > Does anyone want to go thru this and get back to me?
|> >
|> > As I've pointed out I would have written it with a
|> org.jboss.util.TimerTask
|> > in a LRUEntityContextCachePolicy subclass.
|> > In there I would have locked the cache, walked all the
|> cached context and
|> > call setValid(false) on them, more or less like in the
|> > LRUStatefulContextCachePolicy.
|> > What do you think ?
|> >
|> > Cheers,
|> >
|> > Simon
|> >
|> > _______________________________________________
|> > Jboss-development mailing list
|> > [EMAIL PROTECTED]
|> > http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|>
|> _______________________________________________
|> Jboss-development mailing list
|> [EMAIL PROTECTED]
|> http://lists.sourceforge.net/lists/listinfo/jboss-development
|>
|
|_______________________________________________
|Jboss-development mailing list
|[EMAIL PROTECTED]
|http://lists.sourceforge.net/lists/listinfo/jboss-development
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
