On Oct 6, 2009, at 19:29, Eelco Hillenius wrote:
I must admit that I don't get the whole detachable stuff in Wicket.
I'm used
to think in horizontal tiers
where one tier does all the caching "automagically" (e.g. 2nd level
cache in
JPA/Hibernate) and the
other tiers don't know about that fact.
What models in Wicket can achieve is that data is compressed between
requests. This is important because Wicket stores component trees in
memory/ on your disk between requests. Obviously the smaller the
better there. Detaching is also important when you work with objects
as your models that might hold on to resources (e.g. session in
Hibernate); detaching lets those objects frees up those resources
after a request.
Eelco
But how is compression related to detaching? And how detaching to
serialization?
I always thought Wicket *serializes* old component trees between
request and for that task I don't need
any detachable stuff. I simply use 'readObject(ObjectInputStream in)'
to re-initialize my state.
And especially with Hibernate I do *not* want my models detached
because I consider a DB lookup to be
expensive and any writable entity is versioned. The session is never
kept in my models because I use EJBs
for DB access, so I keep only EJB stubs in my model objects and those
are fine to serialize.
Do you have any documentation links or classes to start looking for
what's happing when a component
tree is re-attached and/or de-serialized (if this is the same with
wicket)?
