On the topic of flushing the EJB cache
Francois Archambault said...
|So we created our own LRUEnterpriseContextCachePolicy class to be able
|to passivate beans with JMS messages. We actually call the ageOut
|method with the beans key we want to flush by going through the LRUList
|obtains from getList() method. But there is still a problem, the beans
|that are in a transaction don't get passivated.
Simone Bordet added...
>Anyway, what you really need is not a passivation IMHO, but a complete
>reload of the beans that are in the cache from the underlying DB.
Normally
>you can do this using commit options B or C, but you still want to have
A
>and only sometimes (upon JMS message) a behavior like B or C.
>IMHO best solution will be mark all the cached beans for reload,
instead of
>passivating them, and this can be done by a custom TimerTask simply
>extending LRUEnterpriseContextCachePolicy with your cache.
>Check the EntitySynchronizationInterceptor for informations about the
flag
>that marks a bean for reload.
Marc Fleury replied...
>I believe it is a brilliant idea with the wrong implementation, it
belongs
>at the Option A/B/C that informs the container that he should be
updating
>the state of the beans. In other words, passivating is the wrong thing
to
>do you want to be working in the synchronization interceptor.
After reading Simone's and Marc's posts, I agree that passivation is the
wrong way to go. But I don't agree that we want a behavior like B/C as
Simone interprets it. It's really just a matter or reloading the fresh
data when it has been changed... And we know exactly when data was
changed because we control the other application. I think Simone nailed
the real solution when he wrote we should simply mark beans for reload.
<background>
What we are facing is an interesting challenge. Our company believes in
J2EE and is willing to transform our fat-client VB 6 based architecture
to a distributed architecture built on J2EE. That's a good thing (TM).
But our software is very large and cannot be converted in a one-shot
operation. There will be an overlap during which the VB app will poke at
the repository while JBoss serves EJBs. That's not such a good thing! :)
Commit options B/C _would_ support this architecture, but with a heavy
price IMO... no caching of entities, even ones that are _unlikely_ to
change. But, life being what it is, they _will_ change and we have to
make sure the changes are
propagated to JBoss.
</background>
So we are implementing the approach recommended by Simone and will keep
you guys posted with our results. Our follow-up
discussions will be made on JBoss-dev as we face (probably) more
technical challenges ;-)
<pat-on-the-back>
Francois and I come from the Orion server world, and quite frankly, made
the move to JBoss mainly because of a lack of support on the discussion
list from Orion. It is a very refreshing change to see the energy and
drive of people involved with JBoss.
You guys have created a strong community and it's exciting to be part of
this venture with the rest of you.
Keep up the excellent work!
</pat-on-the-back>
Daniel
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
