In my current project I do just that and it works fine. I must add that
it is a highly interactive application, so I work with long
conversations (managed hibernate sessions), where the transaction is
committed only after a number of request/response cycles after the user
clicks on 'save'.
You shouldnt put that object directly in a CPM, but have a loadabled
detachable model in between. Because now you probably have that hib
object in the page between requests
On 28/02/2009, Stephen Swinsburg s.swinsb...@lancaster.ac.uk wrote:
Hi all,
I'm after your thoughts on the following
Let's say you have a Java object with 20 fields that's mapped to a
database using Hibernate. I don't see that there's much difference in
terms of memory utilization between using that object as the model and
creating a separate object with 20 fields to use as the model.
Following the
i didnt say you have to have a different object.
I just say dont keep persistent objects in memory between requests. Use
detachable for that.
The only exception i guess is when you create a new object that isnt
persisted yet to the db and you have some kind of wizard to fill it up.
On Sun, Mar
Johan,
I was trying to say, in a confused kind of way, that standard practice
is to back a form up with a bean of some kind, and that replacing that
bean with a persistent object wouldn't necessarily increase memory
utilization enough to bother with a detached model. On the other hand
Hi all,
I'm after your thoughts on the following method.
Suppose there is a wicket form with some fields that can map directly
to a simple Hibernate object, and hence a db table. Is it safe to
simply wrap this object in a CompoundPropertyModel and use it as the
backing model for the form?
Hello Stephen,
Does not sound like a problem to me. As long as your hibernate session
is closed after the save you do, this object will be in a detached
state and generally should cause no trouble (same goes for if you
fetch an object from the database thru hibernate).
Martijn
On Sat, Feb 28,
