Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

Is that the right statement that I can not use objects in the session that extend java.util.HashMap. Since BeanUtils are used very offten in the presentation tier like Struts - HashMap is very convenient object. Isn't this potentially a significant limitation?

Currently java objects that extend "logically managed classes" (e.g. java.util.HashMap) are not portable through Terracotta (this is true for logically managed classes only due to the way the JVM manages these classes, and not for all java.util.* and only in Terracotta versions pre 2.2). Note that this does not mean that HashMap is not portable, but only objects that EXTEND HashMap. This is not really a limitation as you can easily get around this by using composition (and delegation) instead. Personally, I think this is a better design practice in most cases anyways.

e.g. If you would like to share instances of FooMap across JVMs,

Instead of

Code:

 Class FooMap extends java.util.HashMap {
 
 ...
 
 }

do

Code:

 Class FooMap {
 
 private Map fooMap;
 
 public FooMap() {
 
 fooMap = new HashMap();
 
 }
 
 // Delegate methods to fooMap
 
 public int size() {
 
 return fooMap.size();
 
 }
 
 ...
 
 }

As far as sharing the sessions in a WebApp which utilizes Apache Commons BeanUtils: the BeanUtils component provides easy-to-use wrappers around Java Reflection and Introspection APIs. Most applications using these wrappers should be keeping their state local to the JVM. Would it be possible for you to elaborate your use case - e.g. what state does the app push into the Session and how do BeanUtil wrappers end up in the Session? Feel free to send me an email at kbhasin@terracottatech.com.

Regards,
Kunal Bhasin.

Hi aizmaylov,

An important clarification -- as of our most recent open source, stable release, we do support sharing roots that extend logically managed classes. This was added in 2.2.