One of the things that makes WO very simple compared to Tapestry is that you don't have to worry about your pages and sessions (and therefore your business objects) being serialized between requests. Therefore, you don't have aliasing issues with your business objects. When using Tapestry, your business objects may be serialized and deserialized between requests if you leave them laying around inside page instances. The result of this is that business objects that get serialized become 'aliased' unless special care is taken. You will have two objects in the VM that really should be a single object.
I've come up with a quick work-around playing footsie with the Externalizable interface and making a superclass for all my business objects that serializes Identities instead of real objects, and then looks them up out of the cache when they are deserialized using the special 'readResolve()' method to replace the Identity with the real object. This seems to work, but first of all it breaks the idea that business objects don't need to extend or implement any special super-class or interface in order to be persisted. Secondly, I do not know how this interacts with dynamic proxies and collection proxies. Do they need special handling?
I imagine there must be a better way to do this, though. First of all, this limits me to using a single PersistanceBroker object inside of each VM since my superclass calls 'defaultPersistenceBroker()' whenever it wants to serialize and deserialize an object. Is this a problem? Is there usually a reason to use more than just the default PersistenceBroker? Secondly, what happens to my objects if they move cross-VM?
Is EJB the answer? If I use a PersistenceBrokerBean, will all these issues be wrapped up in a clever proxy layer? According to the Tapestry docs, it never attempts to store or copy an EJB, but only a handle. How greatly is performance affected by needing to call RMI methods each time the object gets altered? How about JCS or a similar distributed caching mechanism (I know OJB comes with JCS support)?
Thanks for any advice that you might have.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
