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!!
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
