|Marc,
| What do we call the class? Do we want to put the refresh rate in the
|jboss.xml file? I'd rather see it there than in the jcml file. What do you
You are absolutely right it is a bean based value. Each bean will define the
cache refresh rate.
|think? Also, if we don't have the synchornized block we might have un
|predictable results. Assuming that look ups and adds are pretty fast
|operations on a set it might be better to keep the block synchronized.
well... whatever, I will give you an A on that class, free t-shirt (when I
get them)
marc
|
|Any thoughts?
|
|Vinay
|----- Original Message -----
|From: "marc fleury" <[EMAIL PROTECTED]>
|To: <[EMAIL PROTECTED]>
|Sent: Friday, May 11, 2001 11:20 PM
|Subject: RE: [JBoss-dev] Option D - Take Two!
|
|
|> Almost,
|>
|>
|> The name is misleading the ones that are in the map we know for sure that
|> will be valid since the next interceptor will refresh it, so the name of
|the
|> Map is "validContexts", and in fact they are NOT ctxToInvalidate.
|>
|> | /**
|> | * Collection of context cache keys
|> | */
|> | protected HashSet ctxToInvalidate = new HashSet();
|>
|> Change that to validCtx
|>
|> |
|> | /**
|> | * The cache refresh rate
|> | */
|> | private static int REFRESH_RATE = 30000;
|>
|> We will need to have that REFRESH_RATE in the jcml files at some point it
|> will enable us to set the rate at which we invalidate the cache.
|>
|> | public void init()
|> | throws Exception
|> | {
|> | commitOption =
|>
||container.getBeanMetaData().getContainerConfiguration().getCommitOption();
|> |
|> | if(commitOption == ConfigurationMetaData.D_COMMIT_OPTION)
|> | {
|> | //Start Timer Task Now!
|> | new Timer().schedule(new
|ForceSynchronization(),0,REFRESH_RATE);
|> | }
|> | }
|>
|>
|> | private void register(EntityEnterpriseContext ctx, Transaction tx)
|> | {
|> | }
|> |
|> | private void deregister(EntityEnterpriseContext ctx)
|> | {
|> | }
|>
|> These 2 are only needed in the sync refresh so no need to have
|the methods
|> here at all.
|>
|> | public Object invokeHome(MethodInvocation mi)
|> | throws Exception
|> | {
|> | return getNext().invokeHome(mi);
|> |
|> | }
|> |
|> | public Object invoke(MethodInvocation mi)
|> | throws Exception
|> | {
|> | if(commitOption == ConfigurationMetaData.D_COMMIT_OPTION)
|> | {
|> | EntityEnterpriseContext ctx =
|> |(EntityEnterpriseContext)mi.getEnterpriseContext();
|> |
|> | //In case the invalidator thread wakes up!
|> | synchronized(ctxToInvalidate)
|> | {
|> | //Check if already present?
|> | if(!this.ctxToInvalidate.contains(ctx.getCacheKey()))
|> | {
|> | //If not invalidate cache
|> | ctx.setValid(false);
|> | //and add to the set to make sure it is skipped next
|time
|> | this.ctxToInvalidate.add(ctx.getCacheKey());
|> | }
|> | }
|> | }
|>
|> I argued in the previous mail that we shouldn't synchronize this lookup,
|> there is no need to do so. The worst that can happen is that we lookup a
|key
|> when someone is adding in another thread or we are clearing the
|cache. My
|> guess is that it will return a "false" so that we will refresh the state.
|> But maybe I am wrong, what happens if someone is doing a lookup
|and we are
|> structurally modifying the map, does something horribly wrong happen? We
|> should avoid synchronized constructs at all cost in our interceptors
|because
|> it effectively makes a single point of passage.
|>
|> marc
|>
|>
|> |
|> | return getNext().invoke(mi);
|> | }
|> |
|> |
|> | private class ForceSynchronization
|> | extends TimerTask
|> | {
|> | ForceSynchronization()
|> | {
|> | }
|> |
|> | public void run()
|> | {
|> | synchronized(ctxToInvalidate)
|> | {
|> | //Clear the set. Will force invalidation next time on.
|> | ctxToInvalidate.clear();
|> | }
|> | }
|> | }
|> |}
|> |
|> |
|> |
|> |
|> |----- Original Message -----
|> |From: "marc fleury" <[EMAIL PROTECTED]>
|> |To: <[EMAIL PROTECTED]>
|> |Sent: Friday, May 11, 2001 7:58 PM
|> |Subject: RE: [JBoss-dev] RE: Option D - Take One !
|> |
|> |
|> |> |Marc,
|> |> |
|> |> |Will do over the weekend! Just had time today to give this a
|try! [and
|> |that
|> |> |too about 45 mins!]. But I'll see to it that I go thru the material
|and
|> |do
|> |> |it the way you'd like to see it work!!
|> |>
|> |> Great... btw I forgot to welcome you and congratulate you for taking
|the
|> |> courageous plunge of hacking the container interceptors for your first
|> |> server contribution.. that is definitely ballsy. I realize the class
|> |wasn't
|> |> lost at all since you have a firm grasp of the graph of flows,
|> |the plugins
|> |> the JMX init and the invoke detyped mechanisms (you took the right
|> |decision
|> |> for the interceptor).
|> |>
|> |> <PLUG> The training can turn all of you in container developers
|</PLUG>.
|> |So
|> |> you go and get that algo right and lightweight and we put it in.
|> |>
|> |> regards
|> |>
|> |> marc
|> |>
|> |> PS: PLEASE READ THE CLASS EXCERCISE AND MY PREVIOUS MAIL :)
|> |>
|> |> |
|> |> |Cheers,
|> |> |
|> |> |Vinay
|> |> |
|> |> |Just took a loo
|> |> |----- Original Message -----
|> |> |From: "marc fleury" <[EMAIL PROTECTED]>
|> |> |To: <[EMAIL PROTECTED]>
|> |> |Sent: Friday, May 11, 2001 7:12 PM
|> |> |Subject: RE: [JBoss-dev] RE: Option D - Take One !
|> |> |
|> |> |
|> |> |> 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
|> |> |
|> |> |
|> |> |_______________________________________________
|> |> |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
|
|
|_______________________________________________
|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
