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
