Hi Geoff,I believe that the proposal I made deals with a simpler case, and that a solution to your issue requires a bit more discussion. I still believe that allowing ordinary (not framework components) servlets and classes used by servlets to statically "inject" PersistenceManagers is useful. Now, to your interesting component case...
On Oct 11, 2006, at 11:43 AM, Geoff hendrey wrote:
How do we deal with the fact that any components stored in a Page state (wicket/tapestry lingo) need to be serializable?In the case of wicket, Page is serialized all the time, not just when clustering is applied. The pages are serialized and deserialized in order to minimize the memory footprint of an application when there are lots of concurrent sessions. You can't put ANYTHING into the Servlet session, or any page state variable, in any real application, that isn't serializable. If you do, you are back to the "sodding" solutions of proxies, activation/ passivation-type callbacks, hell-on-earth-bad-programming-paradigms.In Shades, I've addressed this by making the DatabaseSession (equivalent to PM) serializable. This is possible because the DatabaseSession does not hang on to connections.
If you are willing to stipulate that PersistenceManagers must not hold onto connections between transactions, and that PersistenceManagers are only serializable between transactions, then we can talk about the requirements for PersistenceManagers to be serialized.
First, allow me to point out that there are many similarities between serialized instances and detached instances. (You can create a detached instance by serialization of a "live" instance). But we made a conscious decision in JDO to not allow a detached instance to "become" a live instance because of the inherent conflict of an instance in the cache with the same identity as the instance to be attached. I believe that if we disallow this use case, we can think in terms of serializing the PM by detaching via serialization all of the instances in the cache.
We then need to make sure that the instances in the cache are actually prepared for serialization by the PM at any time that serialization can occur. If we accept the restriction that this is only between transactions, then the commit boundary is where preparation for serialization occurs.
We now have to look at the user-implemented serialization and deserialization protocols. We need to make sure that the state changes done by the user-defined behavior don't conflict with the needs of the PersistenceManager. Specifically, we would want to require that all persistent fields be serializable.
During deserialization of the PM, the instances in the cache would have to be changed similar to the changes done during attachment (the attachment of a StateManager, replacement of Collection-typed fields with a state-tracking Collection, etc.)
With these considerations, I'd say we could design a model for serialization of PM that works for you.
Also, I mentioned a long time ago that users WOULD want to keep a PersistenceManager-per-session, and I recall postings on JDO central where users asked for it. There seemed to be very little support for this idea. I'm following this thread somewhat loosly, but are we now saying PM-per-session is a valid pattern that we want to support? At the time I proposed this, detachment was the prefered alternative. (I continiue to believe detachment is an anti- pattern that arrises because of the non-serializability problem of the PM, and in situations where the web programming model is fundamentally broken ...E.G Struts).OK, I've stirred the pot a bit. :-) don't take it the wrong way.
I always appreciate well-thought comments. Craig
-geoff
Craig Russell Architect, Sun Java Enterprise System http://java.sun.com/products/jdo 408 276-5638 mailto:[EMAIL PROTECTED] P.S. A good JDO? O, Gasp!
smime.p7s
Description: S/MIME cryptographic signature
