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.
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.
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 ;-)
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!
Daniel
___
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
