On 7/15/06, Iman Rahmatizadeh [EMAIL PROTECTED] wrote:
Hi,
AFAIK, there are three ways of implementing application transactions,
lazy loading, etc. stuff with Wicket Hibernate :
1 - The hard way, where you pass object ids, and load save them in
each request cycle using a new session
2 -
Nathan Hamblen wrote:
As others have pointed out, the magic of IModel works better than you
think (or thought) it does. I often have two constructors for pages, one
taking bookmarkable parameters and another taking an IModel so that I
don't always have to reload DB objects page to page. It's a
I don't think models have to be implementation details. Sometimes that
makes sense, and in that case I usually like to embed the model class
in the component itself. But lots of other times, you can make the
model so that it can easily be reused by other components, possibly at
the same time. This
its my 2c as well
this is not a wicket-related problem anyhow - its http related problem.
-Igor
On 7/18/06, Eelco Hillenius [EMAIL PROTECTED] wrote:
I don't think models have to be implementation details. Sometimes thatmakes sense, and in that case I usually like to embed the model classin the
Agreed. I don't think there's anything here that needs fixing. I was
just saying that if Iman or anyone else wants to experiment with
extended Hibernate sessions, I think that would be cool. (Reattaching
orphaned Hibernate objects is not a road I would want to go down.)
In the mean time our
As a side note, you still can pass in the full object, even in 1.2,
that is what we are doing in our application constantly. You do have
to be careful to always use the shared model, otherwise you'll get
LazyInitialization exceptions...
Sharing the model between components on one page is a good
I've been successful w/ exactly what Iman is concerned with - keeping
objects alive between requests just isn't necessary. With
detachable-models, you can request your POJOs - and they effectively
become detached (outside of Hibernate session context). You can pass
them between pages and persist
while merge is good for saving the bigger concern is stale data. you pass your pojo to the component, store it as a property, and some request later you read its property - which at this point will be stale because the pojo is detached from the session.
-IgorOn 7/17/06, Vincent Jenks [EMAIL
e: [Wicket-user] Wicket
Hibernate Application Transactions
while merge is good for saving the bigger concern is stale data. you
pass your pojo to the component, store it as a property, and some request later
you read its property - which at this point will be stale because the pojo is
det
The problem with #1 is, first its a bit ugly, second you discard every
persistent instance in each cycle (which is less efficient than #2 or
#3), third you lose the advantages of working passing POJO's between
pages, Like you would call 'new ProfilePage(person.getId())' instead of
'new
On 7/16/06, Iman Rahmatizadeh [EMAIL PROTECTED] wrote:
The problem with #1 is, first its a bit ugly,
Working with objects directly is always the nicest of course. In many
cases, where you just have to display some read-only information, you
don't really need to pass the model all the time
I don't think it is *that* less efficient. Attaching those objects
likely means refreshing them too, so the only gain you would have is
the creation of objects, and those few instances wouldn't even be
noticable, while the extra session size of #2 might be.
What I meant was mostly
Another case I just remembered where performance in #1 will be poor is
where you have a page containing a lot of panels, each of them needing
the model object or one of its associations. In #1 the object will be
loaded per panel, but in #2 or #3 you wont have any extra calls.
Iman
I don't think this is true if you create a hibernate session per http request
Juergen
On 7/16/06, Iman Rahmatizadeh [EMAIL PROTECTED] wrote:
Another case I just remembered where performance in #1 will be poor is
where you have a page containing a lot of panels, each of them needing
the model
Juergen Donnerstag wrote:
I don't think this is true if you create a hibernate session per http request
Juergen
When you pass the object id instead of the object to the panels, each
panel will retrieve the object independent of others. Maybe a cache will
help. But still it goes through
But that really depends on how you structure your models. If you use
models that do the loading once on attach, cache the results, and then
unload on detach, you wouldn't have the double loading if you share
the model. Instead of passing ids around, you pass around the model of
course. Besides
But you can pass the models too. It's not only a choice of either
passing in the object or their ids. And even if you would go through
the persistence layer, within the same transaction I think Hibernate
caches your objects too, so that would just be a very slight overhead.
Eelco
On 7/16/06,
yeah, you miss something. load-by-id is a cheap operation. first of all session.get(id) will return the cached object within the same request. and even if the first level cache misses(the session) the second level cache will most likely have the object where it is kept across requests.
so if you
Hi,
AFAIK, there are three ways of implementing application transactions,
lazy loading, etc. stuff with Wicket Hibernate :
1 - The hard way, where you pass object ids, and load save them in
each request cycle using a new session
2 - The detached object way, where you attach the old objects in
I never actually used 2, so I wouldn't know of problems, but 1 is more
space efficient, while 2 is not that much resource (processor,
database) efficient, so 1 would have my preference anyway.
I think 3 makes sense if you have a good business reason for that. But
I haven't seen a lot of actual
#1 may sound hard, and you might think you're missing out on some good
Wicket abstraction, but it can work seamlessly. Once the objects are
loaded, you shouldn't have to think about their database IDs again. An
IModel implementation can do the grunt work internally:
21 matches
Mail list logo
