Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

pepemax wrote:

Do you know why that may be?

The *why* is because under the covers Terracotta is removing a real Java object, and then later adding a new one. Your code never knows the difference, but at the Java level, the reference has changed.

So, it's a bit like serializing and de-serializing an object - you'll lose the transient field in the process.

The fix is to restore the handle to the lost transient data using the onLoad method, per Sergio's answer.

I did this too. Probably should update the docs.

TerracottaUser wrote:

How will the Terracotta server process such a situation? Will changes to object1 and object2 be applied on Terracotta server or will it discard these changes because they are incomplete?

The server will either process the txn or not - atomically.

ConcurrentHashMap already supports this operation:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/ConcurrentHashMap.html#putIfAbsent(K,%20V)

You may be wanting a memoizer, which I described here:

http://javathink.blogspot.com/2008/09/what-is-memoizer-and-why-should-you.html

I think the latest TC (Darwin) will be including this functionality in ehcache too, Ari would probably know better.

You should use tim-messaging.

Everything you need to use it is documented here:

http://forge.terracotta.org/releases/projects/tim-messaging/

What's your tc-config.xml look like? Did you add the masterworker tim to it?

Try running the Terracotta console - how many connected clients do you end up with?

Your join queries will go to the DB where the results will be computed, and returned to hibernate as a list of ids.

If those ids are pre-loaded into the cache, then instead of going back to the db to load the data, hibernate will pull from the cache.

rvandort wrote:

Below a sample program illustrating the Hazelcast transaction mechanism on memory doing a rollback on request.

This is only possible because Hazelcast supports a limited number of datastructures. The datastructures roll back, but not the data itself. Remember that Terracotta clusters - and allows fine-grained updates to -basically any arbitrary object. Hazelcast only supports Hashmaps, Sets, Lists, etc. that contain "objects" only in the sense that they are serialized deep copies from one JVM to the next.

A fully clustered JVM implementation like Terracotta with transactional support as you suggest is an STM. Per my previous post, there are a few experimental STMs but nothing with the production history of Terracotta.

In a specific context, it's possible to wrap JTA around updates since the context is known - e.g. an EHCache instance.

In a generic context, supporting JTA by Terracotta would amount to an STM. There are a few experimental STMs out there, but nothing of the production caliber of Terracotta.

That's why you don't see the implementation yet. As you can see, Terracotta is pretty focused on the specific context - delivering great products around EHCache and soon I suspect Quartz.

2x2 isn't recommended because a single node failure guarantees multiple Terracotta node failures. In your case that triggers the 2 minute wait as the passive server that takes over is waiting for the client to join (which it will never do since it died along with the active server).

At a minimum it is recommended to have Terracotta Server instances on their own dedicated hardware.

If it makes sense you can have more than one client instance on a single piece of hardware, though usually it doesn't make any sense to do such a thing.

Of course this isn't the actual problem you seem to be running into - but that's the reason 2x2 isn't recommended.

You may have run into a bug - the 2x2 deployment isn't a recommended configuration.

This forum post seems related to what you are seeing: http://forums.terracotta.org/forums/posts/list/2775.page

If there isn't a bug already I would recommend adding one to http://jira.terracotta.org

[EDIT]
There is a bug submitted for post 2775 - it's here: https://jira.terracotta.org/jira/browse/CDV-1436

Are you waiting 2 minutes?

In your configuration, by default your cluster won't move forward for 2 minutes because of the fact that when you pull the plug, and the L2B becomes active coordinator, it will wait 2 minutes for L1A to connect.

This is a controllable setting of course, but by default you'll need to wait the 2 minute default timeout period before receiving an event.

If I recall correctly, this type of direct Spring support was removed in Terracotta 3.1 - so I think before you move forward it might make sense to upgrade to Terracotta 3.1 and then make the appropriate changes to your application/tc-config.xml.

It seems to me the Spring Batch forums would be a better place to ask this question.

http://forum.springsource.org/forumdisplay.php?f=41

As for support of Spring Batch, in my understanding there are experimental versions of clustering support for Spring Batch for TC, although as Ari says the design of Spring Batch assumes a database and doesn't really gain much value when introducing Terracotta.