You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Cherry Development <av...@cherrydev.com> on 2003/11/04 22:18:15 UTC
OJB, Tapestry, Serialized Objects and a quest for answers.
First, some background:
I'm a WebObjects (among other technologies) programmer and have decided
to make a move to Tapestry for a new project, it seeming like the most
similar to the style of development I'm used to. For database
technologies, I've decided to use jakarta OJB.
Now, the main architectural difference between WO and Tapestry seems to
be the fact that Tapestry strictly pools, saves and restores pages
between requests, while WO pages are generally instantiated and hang
around in memory. The WO architecture seems to be less memory
efficient, but simpler and more flexible to use, since I don't have to
worry about resetting pages between requests, or worry about the
effects of serialization of all of my objects.
So, my question seems to be this: How can one insure the identity of
persistent objects between requests if they become serialized? If the
same persistent object is being used by two different sessions and each
reference to the object becomes serialized separately, this has the
effect of cloning the object when these references are de-serialized.
Does anybody have experience with using OJB inside of Tapestry in this
way?
I can think of a few different approaches to this situation:
1) Set up all persistent objects so that when they are serialized,
store the Identity of the object instead of the real object. How would
this interact with dynamic proxies, though? I also don't like the idea
of forcing all of my objects to have to be subclasses of a particular
class, though, to implement this, as it defeats some of the purpose and
freedom of OJB.
2) Try to work around the serialization of page and session objects by
storing OJB objects in a in-memory cache. I think this is an
unacceptably cumbersome solution, though.
3) Alter the serialization mechanism of Tapestry so that it treats
persistent objects separately, and implements (1) without having to
alter the classes themselves. Is this even possible? I know EJB
objects are handled like this.
4) Set up OJB to return objects that are all EJBs. I've never worked
with EJB before so I don't really know if this is the proper solution.
I know OJB can be set up to vend EJB objects, though. Will this
transparently work between
Advice? Wisdom? Example code? Best practices?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: OJB, Tapestry, Serialized Objects and a quest for answers.
Posted by James Iry <ja...@hotmail.com>.
Avi,
Even if you get identity all the way up into the web tier, you still have to
think hard about transactional concepts.
Some examples:
What about transaction isolation? If user 1 is working through a complex
wizard that modifies persistent object Foo1 in multiple steps, should other
users be seeing the weird versions of Foo1 that exist before the wizard is
complete? If user 1 modifies object Foo1 and clicks "save" but the database
can't accept the changes because of a constraint violation or because the
database was down, should other users see the transient changes that were
made to Foo1 but weren't ever persisted? If Foo1 can't be saved, should
user 1's session roll the in-memory Foo1 back to its earlier state? What if
other users have also been modifying Foo1 in the meantime? What if user 1
is in a multi step process involving two related objects, Foo1 and Bar1?
Should other users see the temporary situations where the state of Foo1 is
inconsistent with the state of Bar1? Should user 2 be allowed to make
changes to Bar while user 1 is modifying Foo1? What if the end result is an
inconsistency between them? What about consistency in a multiple server
environment? Shouldn't a user who is routed to server 2 see the same version
of Foo1 as users who are routed to server 1?
Just some thoughts.
-----Original Message-----
From: Cherry Development [mailto:avi@cherrydev.com]
Sent: Tuesday, November 04, 2003 10:42 PM
To: Tapestry users
Subject: Re: OJB, Tapestry, Serialized Objects and a quest for answers.
On Nov 4, 2003, at 6:06 PM, Bill Lear wrote:
>> ..... However, when you're running a web application with complex
>> logic, your business objects are not going to be simple data
>> structures, but they still need to fit inside your web application
>> framework.
>
> Well, I'll let you figure this out for yourself, but I can't see how
> this assertion makes any sense. My business objects are complex data
> structures and they have no need to "fit inside" Tapestry. What you
> are talking about is using serialization as a cache, nothing more. I
> see that as vast overkill, but perhaps you think otherwise.
Here is a fairly simple example of what I'm talking about:
Two user sessions (A & B) are making changes to a particular business
object, x. This normally wouldn't be a problem because there is only
one object x. Changes to x should be seen immediately by either
session, because they are altering the same object.
However, according to the Tapestry Documentation (the User Guide, which
is supposed to be up-to-date, if not completed), Tapestry may at any
time serialize and de-serialize any compound object.
From the docs:
> Each persistent page property is stored individually as an HttpSession
> attribute. Like the Servlet API, persistent properties work best with
> immutable objects such as String and Integer;. For mutable objects
> (including List and Map), Tapestry makes acopy of the property. In the
> worst case, Tapestry may have to serialize and deserialize the object
> to make a copy.
THERE is the problem.
Session A begins, a request cycle starts(A.1), pulls object x from the
database, placing it into a page property.
Cycle A.1 ends. All page properties are COPIED into the HttpSession.
This might involve serializing and deserializing the object. Object x
is not stored in the session, but a copy, x1.
Session B begins, a request cycle starts (B.1), pulls object x from the
database (cached), placing it into a page property.
Cycle B.1 ends. etc etc. Another copy of x is created and placed into
the session, x2.
Session A and session B now have objects that are not the original x,
but clones. Changes to x1 do not happen to x2. They will not contain
the same data until they are refreshed from the database or cache. x
has now lost its unique identity, as there are now 3 of them floating
around in the VM.
This is how -I- understand the documentation. If I am wrong about
this, PLEASE tell me, as it will make my life much more simple. I am
obviously a total newb at this and have not (yet) mucked about with the
internals of Tapestry to see how this happens.
All I want to know is how to maintain identity of my business objects
when they are inside persistent page properties.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OJB, Tapestry, Serialized Objects and a quest for answers.
Posted by Cherry Development <av...@cherrydev.com>.
On Nov 4, 2003, at 6:06 PM, Bill Lear wrote:
>> ..... However, when you're running a web application with complex
>> logic, your business objects are not going to be simple data
>> structures, but they still need to fit inside your web application
>> framework.
>
> Well, I'll let you figure this out for yourself, but I can't see how
> this assertion makes any sense. My business objects are complex data
> structures and they have no need to "fit inside" Tapestry. What you
> are talking about is using serialization as a cache, nothing more. I
> see that as vast overkill, but perhaps you think otherwise.
Here is a fairly simple example of what I'm talking about:
Two user sessions (A & B) are making changes to a particular business
object, x. This normally wouldn't be a problem because there is only
one object x. Changes to x should be seen immediately by either
session, because they are altering the same object.
However, according to the Tapestry Documentation (the User Guide, which
is supposed to be up-to-date, if not completed), Tapestry may at any
time serialize and de-serialize any compound object.
From the docs:
> Each persistent page property is stored individually as an HttpSession
> attribute. Like the Servlet API, persistent properties work best with
> immutable objects such as String and Integer;. For mutable objects
> (including List and Map), Tapestry makes acopy of the property. In the
> worst case, Tapestry may have to serialize and deserialize the object
> to make a copy.
THERE is the problem.
Session A begins, a request cycle starts(A.1), pulls object x from the
database, placing it into a page property.
Cycle A.1 ends. All page properties are COPIED into the HttpSession.
This might involve serializing and deserializing the object. Object x
is not stored in the session, but a copy, x1.
Session B begins, a request cycle starts (B.1), pulls object x from the
database (cached), placing it into a page property.
Cycle B.1 ends. etc etc. Another copy of x is created and placed into
the session, x2.
Session A and session B now have objects that are not the original x,
but clones. Changes to x1 do not happen to x2. They will not contain
the same data until they are refreshed from the database or cache. x
has now lost its unique identity, as there are now 3 of them floating
around in the VM.
This is how -I- understand the documentation. If I am wrong about
this, PLEASE tell me, as it will make my life much more simple. I am
obviously a total newb at this and have not (yet) mucked about with the
internals of Tapestry to see how this happens.
All I want to know is how to maintain identity of my business objects
when they are inside persistent page properties.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OJB, Tapestry, Serialized Objects and a quest for answers.
Posted by Bill Lear <ra...@zopyra.com>.
On Tuesday, November 4, 2003 at 16:00:03 (-0800) Cherry Development writes:
>On Nov 4, 2003, at 3:20 PM, Bill Lear wrote:
>..... However, when you're running a web application with complex
>logic, your business objects are not going to be simple data
>structures, but they still need to fit inside your web application
>framework.
Well, I'll let you figure this out for yourself, but I can't see how
this assertion makes any sense. My business objects are complex data
structures and they have no need to "fit inside" Tapestry. What you
are talking about is using serialization as a cache, nothing more. I
see that as vast overkill, but perhaps you think otherwise.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OJB, Tapestry, Serialized Objects and a quest for answers.
Posted by Cherry Development <av...@cherrydev.com>.
On Nov 4, 2003, at 3:20 PM, Bill Lear wrote:
> Isn't is usually recommended that persistent attributes be "simple"
> data structures and not full-blown (complex/heavy) domain objects?
> Bringing in from a global, with cache if needed, seems a better
> solution than using serialization.
This actually underscores my point. Complex objects don't serialize
well. However, when you're running a web application with complex
logic, your business objects are not going to be simple data
structures, but they still need to fit inside your web application
framework.
I've made a base class for my OJB objects that uses the Externalizable
interface and the special 'readResolve()' method to do object
replacement. When it stores an object, it looks up its Identity, then
stores that. When it reads it, it reads the Identity, then pulls the
'real' object out of the persistence broker and replaces the original
object using the readResolve() method.
This seems to work, but I'm unsure how it will behave with proxy
objects.
I've also found the PersistenceBrokerBean which says that it allows OJB
objects to be taken outside of the VM, but I don't know how it works or
what limitations it has.
Perhaps I should also try from the other end and ask the jakarta OJB
people how I should deal with this.
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OJB, Tapestry, Serialized Objects and a quest for answers.
Posted by Bill Lear <ra...@zopyra.com>.
On Tuesday, November 4, 2003 at 14:35:52 (-0800) Cherry Development writes:
>...
>A quick look at Marilen Corciovei's example page shows no database
>objects hanging around inside page objects to be serialized. Instead
>they are brought in from a global at every single request. I'm looking
>to avoid this, as is it cumbersome and very much shatters the
>'illusion' that tapestry pages can hold persistent attributes between
>requests.
Isn't is usually recommended that persistent attributes be "simple"
data structures and not full-blown (complex/heavy) domain objects?
Bringing in from a global, with cache if needed, seems a better
solution than using serialization.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OJB, Tapestry, Serialized Objects and a quest for answers.
Posted by Cherry Development <av...@cherrydev.com>.
Well, first off, OJB seems similar in many ways to the persistence
layer that WebObjects comes with, Enterprise Objects Framework and I
don't so much mind working with a somewhat cumbersome system as long as
it keeps me from pitfalls in the future.
Second of all, one of the goals of ANY persistence database layer is to
maintain identity of objects and to assure that there is only one copy
of an object floating around at once. This doesn't just apply to OJB.
Also, to head off any discussions of OJB vs. Hibernate, vs.
persistence-layer-of-choice, this also applies to Hibernate, which
seems more commonly used than OJB with Tapestry.
A quick look at Marilen Corciovei's example page shows no database
objects hanging around inside page objects to be serialized. Instead
they are brought in from a global at every single request. I'm looking
to avoid this, as is it cumbersome and very much shatters the
'illusion' that tapestry pages can hold persistent attributes between
requests.
On Nov 4, 2003, at 2:23 PM, Bill Lear wrote:
> Perhaps unwelcome, but OJB seems terribly cumbersome, and not a
> very good fit. Why not use iBatis, for example?
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: OJB, Tapestry, Serialized Objects and a quest for answers.
Posted by Bill Lear <ra...@zopyra.com>.
On Tuesday, November 4, 2003 at 13:18:15 (-0800) Cherry Development writes:
>...
>Advice? Wisdom? Example code? Best practices?
Perhaps unwelcome, but OJB seems terribly cumbersome, and not a
very good fit. Why not use iBatis, for example?
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org