On 03/05/2013 9:58 AM, Christian Reiter wrote:
I don't use JPA anymore, so this is from memory. If you store the JPA
entity objects directly, you're actually storing the proxy objects
created by your JPA provider to handle lazy-loading and such. This means
you're probably serializing the entity manager as well! That would
explain your session size issue. You can use dto (data transfer objects)
instead which will not take much room in the session. This means you'll
have to transfer data between the dto and the entity.
I'm wondering what's the recommended way to store a unpersisted object
while it is edited (I'm using EJBs with JPA as backend).
Let's imagine I want to build a customer editor which should be able
to handle editing of new (unpersisted) and existing (persisted)
If I use a loadable detachable model to load the customer from the
backed, all unpersisted changes between requests are lost - not really
desirable. If I use a simple model which stores the entity in
serialized form my sessions are growing and in addition I've to handle
entity refreshing if a user navigates back to the page by using the
browser's back button to prevent the user from saving an old entity
One way or another you must store the edited values between requests if
the client doesn't send them back as part of a form. If using dto still
makes your session size too large, you can store the temporary data in
the database and keep an id pointing to that data in the session.
Best solution I can imagine would be if there would be a callback or
overridable method which is called when the user navigates to a page
and another one which is called when the user leaves a page. Those
methods would be great to prepare and cleanup models. Are there such
No method will reliably inform you that a user left a page. His WIFI
could die, the power could go out, etc. You must clear all expired
temporary data after some time. If your data is stored in the session,
that's done automatically for you.
I hope this helps.
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org