Tomcat castor and Ehcache distributed environment

Just to make sure, you managed to resolve this by making the Identity class implement java.io.Serializable, correct ?

I'd suggest to address the different issues mentioned in the readme individually. As such, I'll add a sub-task to make the Identity class implement java.io.Serializable first, and we'll take it from there, okay ?

Just looking at the ClassCastExceptions ... lines 278ff of SqlTypeConvertors defines the following convertor:

new Convertor(Integer.class, Boolean.class) {
public Object convert(final Object obj, final String pm) { return new Boolean(((Integer) obj).intValue() != 0); }
}

which happens to be converting Integrer instances to booleans. Any idea why you are being passed a String instance ?

And finally, I do have a theory (but not more) as to why you are seeing these exceptions. It looks like you are trying to do long transactions, correct ? With Castor JDO, this means that the entity in question has too implement the TimeStampable interface, and that a cache has to be used for these entities. Every time you load an entity that implements TimeStampable, the time stamp associated with this entity will be updated in the cache as well, to highlight the last access to this entity. This is necessary so that Castor JDO can detect if (e.g. another thread) has already changed this entity when you call Database.update() .. throwing a ObjectModifiedException as a result.

When you use EHCache as cache provider for this entity, EHCache will replicate the cache content in your cluster, and for entities that implement TimeStampable, this will include the timestamp as well.But that means that if you happen to load the same instance in two threads, and one changes (updates) this instance later, this entity's information (incl. the time stamp) will be replicated through-out your cluster. As a result, when the other thread tries to perform the update operation, you'll get the exception you are seeing.

Does this make any sense to you ?

Just going back to my own explanation from above. I'd personally consider this 'third' exception to be semantically correct. Just imagine you would not get that ObjectModifiedException: in that case you would risk overwriting values from another thread that happened to be 'updating' the entity in question earlier than you. I am still not a 100% sure about all this, but let me have a closer look at the load() operation for 'TimeStampable's.

Is it an option for you to get the latest sources from SVN, and build the JARs yourself ? If yes, you could in addition insert a new LOG statement at line 278 of that SqlTypesConvertor to see what it is that is causing the ClassCastException ? If not, I could ship a new snapshot release of 1.1.2, even though I do not really like the idea of adding debug statements on purpose to a release. Let me know your preferences.

Gonzalo ?

I really wonder whether I managed to explain the OME to you in such a way that you realize that the behaviour you are seeing is 'expected behaviour' ?

Hello Werner,

Sorry I didn´t answer you... I have been moving things to production and I didn´t have time to work on this isue.

Any way... I understand de behaviour about the timestamp but that makes ehcache send information and look thinks all the time for read only operation.

I wander if there is a way of telling castor that a query is a read only. That way the timestamp is not important and the object doesn´t change making ehcache send the modified object throught the network.

In my case, the application is mostlly read only but with a lot of users doing queries, this makes a lot of unecesary network trafic between application instances for ehcache...

I will try to find time and work on this...

Regards,
Gonzalo Abollado.

Before trying to answer your question(s), let me just ask you one question first: if your domain object in question is read-only, how come you are using the Database.update() call at all ? It just does not make sense to me. If a domain object is read-only, it implies that it will never change during its life-time. That means that never ever anybody should have to use long transactions for such domain objects. Looks like I am getting something completely wrong.