On 9/12/06, Pierre-Yves Saumont <[EMAIL PROTECTED]> wrote:
> Thank you for this clarification. So it appears that, in an unclusterd
> context, the problem is not with storing references *in sessions*, but
> simply with storing references. I am using hibernate objects and I need
> to keep to copies of the data, so I am creating a value object plus I
> keep the original hibernate object. Perhaps I would better create 2
> value objects and throw away the hibernate object (in case this object
> is much bigger than a simple value object??). I must check for this.
> (But this is not Wicket related ;-).

A common problem with things like Hibernate objects is that they might
get stale (disconnected from the session they were retrieved in),
which results in problems with things like lazy collections. Also, if
you use a transaction per request (e.g. using servlet filters or a
custom request cycle) like some people have reported doing, you have
to be very careful you're not updating objects you didn't want
updated. The latter is an argument for using value objects (which I
don't like tbh... too much code duplication) and the first is an
argument for using detachable models and thus storing only the minimal
info (if any) for retrieving the proper objects.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
Wicket-user mailing list

Reply via email to