Tuesday, December 06, 2005
POJO + teracotta appl clustering implementation
Date: Dec 5th, 2005
2 presentations:
Pres1: By the author of POJOs in action, email address cer@acm.org
The author describes a lightweight framework using Spring and hibernate to put transaction mgmt, security and other enterprise capabilities to 'plain old java objects'.
The two alternative approaches are use of Spring vs use of EJB 3.0
JDO / Hibernate (persistence) => Spring => POJO
or JDO /Hibernate => EJB 3.0 => POJO
The author deprecated EJB 3.0 framework, claiming that use of JNDI in EJB for object lookups clutters the code badly and adds lot of dependencies.
Spring made heavy use of proxies instead (based upon AOP) to hide the ORM details from the user
The model appears as
Pres Tier ----> Transaction interceptor <==> Platform Trans mgr (Hibernate /JDO)
The author didn't appear very convincing in his argument, especially since EJB 3.0 is more popular and has fixed most of well known defects of EJB 2.0
-----
Teracotta presentation: more interesting part of talk
Talk Focussed on putting caching + clustering + replication / fault tolerance in your application in a transparent way
The talk first pointed out big issues with standard jcache style implementations. In a nutshell, the issues which teracotta framwork avoids is :
1. Page faults , responsibility of write through / write back caches to sync across cluster
2. Cache get/set operations do not preserve object references, causing lot of cache specific code to be written
3. All objects using cache have to be declared 'serializable'
Teracotta takes a radically different approach, based upon instrumentation of existing code instead. It can be thought of as 'specialized AOP' with declarative way of controlling the system caching.
Design: hub and spoke approach; object 'faulted' on demand into a cluster node
Failover planned in next release
2 presentations:
Pres1: By the author of POJOs in action, email address cer@acm.org
The author describes a lightweight framework using Spring and hibernate to put transaction mgmt, security and other enterprise capabilities to 'plain old java objects'.
The two alternative approaches are use of Spring vs use of EJB 3.0
JDO / Hibernate (persistence) => Spring => POJO
or JDO /Hibernate => EJB 3.0 => POJO
The author deprecated EJB 3.0 framework, claiming that use of JNDI in EJB for object lookups clutters the code badly and adds lot of dependencies.
Spring made heavy use of proxies instead (based upon AOP) to hide the ORM details from the user
The model appears as
Pres Tier ----> Transaction interceptor <==> Platform Trans mgr (Hibernate /JDO)
The author didn't appear very convincing in his argument, especially since EJB 3.0 is more popular and has fixed most of well known defects of EJB 2.0
-----
Teracotta presentation: more interesting part of talk
Talk Focussed on putting caching + clustering + replication / fault tolerance in your application in a transparent way
The talk first pointed out big issues with standard jcache style implementations. In a nutshell, the issues which teracotta framwork avoids is :
1. Page faults , responsibility of write through / write back caches to sync across cluster
2. Cache get/set operations do not preserve object references, causing lot of cache specific code to be written
3. All objects using cache have to be declared 'serializable'
Teracotta takes a radically different approach, based upon instrumentation of existing code instead. It can be thought of as 'specialized AOP' with declarative way of controlling the system caching.
Design: hub and spoke approach; object 'faulted' on demand into a cluster node
Failover planned in next release
