The second release of the Enterprise Java Bean 2.0 specification public draft is now available for download on java.sun.com.

Get the Public Draft 2 Specification.

If only the spec went the distance and specified full JavaBeans-style events (using JMS for delivery).

When I heard that EJBs could receive JMS messages, I became very excited that an event system was possible (to promote decoupling, and create read-only beans that refresh intelligently). However, only MessageDrivenBeans can receive messages. Entity beans cannot. DAMN!

Eron,

 What is to stop you from using a MessageDrivenBean and calling your in-memory entity beans and telling them to refresh?

Floyd

How would you know if your entity bean is in memory???

You don't know if they're in memory, because of the interface-based programming methodology behind EJB. But why does that matter?

If the beans are read only and you are pureposfully trying to keep them in memory and "current", then you can just implement a finder that returns all the entity beans of the type you want to cache, and call some sort of "updateMe" method on each bean, at regular intervals.

   There is no actual way to "detect" which beans are in-memory.

Floyd

Exactly my point - since beans are accessible via interfaces only and there is no way to tell if they are in memory or not - that makes JMS-based cache updates impossible to implement.

And I do not think it's a good idea to implement an 'update' method on read-only entity beans. First, because finder will return all beand, not only ones currently cached in memory Second, this is not going to work because implementation may have multiple instances, cluster for example.

Yeah you are right Dimitri. I don't think my cache scheme will work in non-weblogic (optimistic cache) containers.

Floyd