Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

I'm trying to create a terracotta distributed app for the first time and I'm having trouble understanding some of the concepts... Suppose that I have a Collection of objects, say a Collection of orangeObjects and I want to share this collection so that multiple clusters can process the instances inside the collection (ie each instance only gets processed by a single cluster element, so orangeObjectA is processed by machine 1, objectOrangeB processed by machine 2, etc...)

I've declared FruitBasket.oranges as the root where FruitBasket is the class and oranges id the collection. I've also put a write level lock on FruitBasket*.*(..) .Now, my question is what needs to be defined as transient, instrumented and does anything else need to be declred as root ? I tried declaring the root as specified above and Oranges class as excluded under instrumented-classes however I keep getting the following stack trace:

com.tc.object.dna.api.DNAException: java.lang.ClassCastException: com.s6.sphere.common.pojos.Orange
at com.tc.object.TCObjectImpl.setValue(TCObjectImpl.java:192)
at com.tc.object.applicator.PhysicalApplicator.hydrate(PhysicalApplicator.java:103)
at com.tc.object.TCClassImpl.hydrate(TCClassImpl.java:152)
at com.tc.object.TCObjectImpl.hydrate(TCObjectImpl.java:103)
at com.tc.object.ClientObjectManagerImpl.lookup(ClientObjectManagerImpl.java:499)
at com.tc.object.ClientObjectManagerImpl.lookupObject(ClientObjectManagerImpl.java:400)
at com.tc.object.ClientObjectManagerImpl.lookupObject(ClientObjectManagerImpl.java:393)
at com.tc.object.applicator.ListApplicator.hydrate(ListApplicator.java:67)
at com.tc.object.TCClassImpl.hydrate(TCClassImpl.java:152)
at com.tc.object.TCObjectImpl.hydrate(TCObjectImpl.java:103)
at com.tc.object.ClientObjectManagerImpl.lookup(ClientObjectManagerImpl.java:499)
at com.tc.object.ClientObjectManagerImpl.lookupObject(ClientObjectManagerImpl.java:400)
at com.tc.object.ClientObjectManagerImpl.lookupRootOptionallyCreateOrReplace(ClientObjectManagerImpl.java:740)
at com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManagerImpl.java:570)
at com.tc.object.ClientObjectManagerImpl.lookupOrCreateRoot(ClientObjectManagerImpl.java:557)
at com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:288)
at com.tc.object.bytecode.ManagerImpl.lookupOrCreateRoot(ManagerImpl.java:267)
at com.tc.object.bytecode.ManagerUtil.lookupOrCreateRoot(ManagerUtil.java:79)
at com.s6.sphere.crawler.services.FruitBasket.__tc_setnewOrangess(FruitBasket.java)

I was also wondering if someone could explain the following message:

*******************************************************************************
Attempt to access a shared object outside the scope of a shared lock.
All access to shared objects must be within the scope of one or more shared locks defined in your Terracotta configuration.
Please alter the locks section of your Terracotta configuration so that this access is auto-locked or protected by a named lock.

Caused by Thread: pool-1-thread-44 in VM(7)
Shared Object Type: java.util.HashSet
*******************************************************************************

The HashSet is a collection inside the Orange class of instances of another... I'm guessing I also have to declare something in the hc-config but not exactly sure what....

any help would be much appreciated.
Nick.

Nick,

Let me look into the ClassCastException and get back to you, which I'm sure I'll be able to do quickly. However, a couple of things strike me right away. If FruitBasket.oranges is the root, and oranges is a collection of Orange objects (don't know if you're restricting membership in the collection to Orange objects), then you will want to include the Orange class in the list of classes to be instrumented. Also, although you have defined what should be autolocked using *.*, the code that modifies the Hashset still has to be thread-safe. You can achieve this either by using the java synchronize keyword or by defining a named lock around the method that does the mutation. The former is the preferred approach.

I'll follow-up with additional information on the ClassCastException.

Regards,

Gordon
Sr. Systems Engineer
Terracotta, Inc.

thanks.

Nick,

I've researched this, and it doesn't appear there is a bug per se. A couple of thoughts/suggestions -- a) have you tried the suggestion to be sure to include the "Orange" class for instrumentation, and b) since this is experimental code, if you could send either the config file or the config file and code, I would be happy to reproduce what you are seeing and provide a more detailed response. I"ll send you a private message with my email address.