db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig L Russell <Craig.Russ...@Sun.COM>
Subject Re: Proposal for new method (long)
Date Wed, 11 Oct 2006 19:46:35 GMT
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:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Mime
View raw message