By persistent store, I guess what they mean is that the data should be able to survive a container crash, like the data in a RDBMS, such as with entity beans. Passivation may be done by storing the data temporarily on the file system as well, but that does not necessarily guarantee "persistence". That's just my interpretation.
Originally posted by Akasmat de Goa: By persistent store, I guess what they mean is that the data should be able to survive a container crash, like the data in a RDBMS, such as with entity beans.
The question is not WHAT is persistant store, which I am clear on. It just means any storage medium outside the JVM. The spec does NOT provide for the state of a stateful session bean surviving a crash. Anyone else have any ideas? Thanks.
Howdy -- yes, the spec uses "persistent store" to mean something that could survive a server crash. And even though *your* vendor might actually offer crash-proof session passivation, it definitely isn't in the spec. So, persistent store applies only to entity beans, for the purpose of the spec. Of course you're free inside a session bean to do anything you want with a persistent store. The other key point about the phrase "persistent store", in the spec, is that it does not mean a relational database (although it almost always does). But it could be an object database or even a [horror] flat file. But in reality, we almost always think of persistent store == relational database, when we're talking about entity beans. cheers, Kathy
I think we are in danger of muddling issues here. Stateful session bean passivation serves a different role than storage of persistent data. When you talk about persistent data you enter the territory where it becomes useful to distinguish between 'entity' and 'entity bean'. The entity, i.e. the persistent state, is essentially permanent. So long as it has business value, its going to be there. Passivation has nothing to do with business value. The passivated state will be around for as long as the *container* decides it has value. The container can decide that a passivated bean should be removed completely, and that is fair game. This would not be true of an entity bean - the container never spontaneously decides to remove entities, only the client (via the appropriate calls) decides when an entity no longer has business value. So yes, the container could decide that a database is its tool of choice for maintaining passivated state, but I would hesitate to call that 'persistence'. The vendor wasn't looking for persistence so much as short-term robustness. That is why the SessionSynchronization interface exists. It reflects the spec's need to distinguish between passivation and persistance. Passivation is the container's problem. Persistence for a stateful session bean is the bean provider's problem. The container's responsibility is limited to invoking the appropriate callbacks.
Howdy, yes what Reid said I think is a good way to look at it. It's the *spec* definition of persistent vs. maybe a dictionary definition. How the Container chooses to maintain passivated state is not important to us. Some people think of passivation as "semi-persistent" or "quasi-persistent", because of course it IS *saved* state. It could be a database. It could be serialization to a file. It could be a block copy of memory saved some where. So it IS, in a sense, *saved*, but it is *not* considered "persistent storage", as persistent storage, in the spec, relates only to entity beans. When a Container comes back after a crash, it does not have to recover the state of any session beans that were passivated at the time of the crash. And most won't... although again, you might go the Container Store and find one with a bright red sticker on the outside of the box that says, "Now! With Crash-Proof Session Passivation!" cheers, Kathy
WHAT is your favorite color? Blue, no yellow, ahhhhhhh! Tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop