Vinay,
// The valid variables, make it a hashset
Map validContext;
invoke(MI mi) {
try {
// Use the cache key, it is safe
if (!validContext.contains(((EntityEnterpriseContext)
mi.getEnterpriseContext()).key) {
//The context is not in the map, it will be loaded in the next
interceptor
ctx.setValid(false);
synchronized (validContext)
// Add it to the map so that it is seen the next time
validContext.add(... mi.getEnterpriseContext().key...);
}
invokeNext(mi);
}
finally {
ctx.setValid(true);
}
// The thread that does the work should only do the following
synchronized (validContext)
validContext.clear();
The way this work is that when the thread wakes up it removes all the keys
from the valid instances.
You start there is no one in the valid stuff, if a call comes it gets a map
miss and asks for the instance to be reloaded. The next time a call comes
the instance is in the map the ctx is still at valid and the next
interceptor won't load the instance.
When the thread wakes up it empties the map so that the threads coming in
through invoke see that the instance isn't in the validContexts and asks for
a reload of it.
I don't believe that the synchronization of the map is really necessary (at
all) and if it is I don't see it as needed other than the place where there
is structural changes. A "miss" will mean a reload so that treats the state
in a safe way.
regards
marc
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of K.V.
|Vinay Menon
|Sent: Friday, May 11, 2001 11:29 AM
|To: [EMAIL PROTECTED]
|Subject: Re: [JBoss-dev] RE: Option D - Take One !
|
|
|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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
