We call it compressing because you have data X with 10 references to objects. then detaching clears 5 (or something like that) of those references to the objects
So now you graph of objects is not 11 objects but only 6 thats what we call compressing by detaching. The after detaching we serialize the rest of the object tree so also the latest page that is just requested. We have to do that because it has to be serialized before the next request (which can change the page again) so that we have always the right page version stored. On Wed, Oct 7, 2009 at 09:38, Robin Sander <[email protected]> wrote: > > 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)? > >
