Is the Hibernate L2 cache a distributed cache?
in hibernate it is a pluggable implementation. by default it uses ehcache which as of 1.2 has clustering support afaik. but i hope it doesnt replicate entities over the cluster and just replicates the evict calls instead.
Because, if it isn't, just bear in mind that detaching your POJO no longer saves any memory, since the cache is holding a reference to your POJO.
the cache doesnt live in httpsession so that is ok. httpsession is the important part because it is expensive to replicate for clustering so you want to keep it as small as possible. of course expensive is a relative term.
With regard to the Pages, and other session variables, could you walk me through how detachment works in Wicket? I was under the impression that stuff was getting serialized out.
its pretty simple. models have a void detach() method and components have void onDetach(). right before wicket sets the httpsessionattribute for the page - which causes the serialization - it calls ondetach() on the page. the page cascades that call to all its children, and the children to their model.
so right before the component is serialized its model's detach() is called. this gives the model a chance to detach any state it might not want serialized and which it can recreate on the next request from another source. this is done to minimize the size of the serialized model.
so here is such an implementation of imodel
class ContactModel implements IModel {
private final long id;
private Contact cache;
public ContactModel(Contact contact) {
this.id=id ;
this.cache=contact;
}
Object getObject() { if (cache==null) { cache=Database.load(id); } return cache; }
void detach() { cache=null; }
}
hope that example explains it. notice i didnt make cache transient to really drive the point home. so when serialized the model only keeps the long id, the other information is redundant and would be a waste to serialized and replicate because
(a) it can be recreated
(b) db data is volatile, so it needs to be reloaded next request anyways.
I want to point out, that Shades is extemely efficient with regards to memory. First off, in Shades, POJO's loaded by Shades *never* have live references to other POJO's. It's a radical design choice, but one I feel is justified, for both performance, and streamlining. In Shades, if you want to access a non-primitive field of a POJO, you must retrieve it explciitly by query. So when you serialize out a POJO, that was loaded by Shades, you never have to worry that it might have dragged an entire object-web out of the database with it.
yes, but you still dont want to serialize the pojo for the two reasons i outlined in the above paragraph.
Secondly, shades doesn't have this confusing notion of the cache (or "pseudo cache") that JDO has. I really don't think it is well understood by many persitence programmers that the JDO cache is a weak cache. If you are holding onto an ID, for the purpose of clearing the POJO's references from memory, the POJO will NOT be in the cache when you do getObjectByID. The PersistenceManager is going to materialize the POJO, by reading *through* the cache to the database, so you get no performance or scalability benefits from a JDO cache in this environement.
i dont know about jdo but let me tell you what i know about hibernate. in hibernate the session is the first level cache. it is not a weak cache. it is used to guarantee instance identity of loaded entities within the same session.
Finally, and now we are really getting into the realm of religion, a few words about L2 cache. In my opinion, the database *is* the L2 cache. It's got query caching, clustering and replication, and it's got a networked interface, which makes it an "out of process L2 cache". In my opinion, L2 caches implemented in the persistence layer are a crutch to support applications that do N+1 loading.
i dont think this is a religious discussion. here are my two cents on this
local L2 cache has a few very important advantages over the database
(a) locality
it is much much much more expensive to transfer data over the wire compared to transferring it from local ram
(b) scalability
say you have 10 servers in your cluster. you have 10 servers continuously hammering the database for entities that could be cached locally. that is a lot of network traffic that is taking away the bandwidth from replication of sessions and other intra cluster communications.
(c) economics
it is expensive to setup and maintain a database cluster with replication. usually what people do is have a standby backup - but that backup doesnt participate until the main one fails, so you still only have one server answering queries.
a second level cache on the other hand is pretty simple to set up.
of course nothing is without a price
your application has to own the database schema (be the only one writing to it) otherwise your cache might hold stale data. i think there are some implementations of caches that do work outside this scenario as well but i dont have any experience with them.
-igor
Hope this leads to some interesting discussion!
-geoff
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
