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!
2. Users can add and remove it as required from the jboss.xml so that they
have more control over it.
3. Code does not really touch any other code classes [except for the
metadata bit]
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
