Terracotta Discussion Forums

I've been going through a lot of the documentation and the Terracotta Definitive guide discussing how to cluster POJO's, and I was wondering what are the best practices for minimizing a complicated tc-config.xml (with many <auto-lock> configurations).

It seems like most examples show you how to configure Terracotta auto-locks using java's built in synchronized keyword, but i feel like it's clearer in code and in your tc-config.xml to use ReentrantReadWriteLock's. Is the focus in the documentation for code bases that already exist using the synchronized keyword?

I'd imagine that if your application could adopt the use of Java 5's ReentrantReadWriteLock to be used as your synchronization mechanism for all your shared data classes, then all you'd have to specify in your tc-config.xml are your custom classes in your <instrumented-classes> and you could piggy-back on Terracotta's support for ReentrantReadWriteLock's, and in your code it would be a lot more explicit.

Would you still have to instrument classes that modify clustered objects, or would you be able to utilize the read/write locks to lock and publish modifications to clustered objects.

It is certainly a fine strategy - one of our largest customers started with a clean code base and they use ReentrantReadWriteLock exclusively.

You could also use annotations: http://www.terracotta.org/web/display/docs/Annotations

Thanks for the quick reply!!

The annotations are an excellent solution for specifying which classes to instrument, that will make my tc-config.xml even cleaner.

Because we're developing a brand new code base if I adopted Terracotta annotations and ReentrantReadWriteLocks then my tc-config.xml would essentially consist of Terracotta server configuration and statistics directories, and all my application configuration could live with the code as annotations?

This sounds like quite an elegant solution, there should be links to this type of solution in the getting started guides (maybe there is and I just missed them).

You might also want to group related configurations into TIMs

We've begun implementing our terracotta enabled systems in ernest and we've got 2 methods for locking being used, one is using @AutoLockRead/@AutoLockWrite and the other is using name ReentrantReadWriteLocks.

Starting with a fresh system does any of the seasoned Terracotta veterans have a preferance of which way we should go. It'd be nice to consistently use one or the other methods instead of mixing and matching them.

@AutoLockRead/@AutoLockWrite Pros:
- synchronized syntax is cleaner than try/finally lock()/unlock() syntax
- it's clear when synchronizing on a Collection object as to what it's guarding

@AutoLockRead/@AutoLockWrite Cons:
- When running in single node non-terracotta mode our application will be multithreaded and hitting synchronized read blocks will be the same as hitting write blocks (I assume we won't have the terracotta instrumentation in place). Maybe we shouldn't be having multiple threads in a single Terracotta application accessing the same shared data?

Pros ReadWriteLocks:
- Named locks are sometimes clearer when your locks guard multiple objects states (e.g. a lock guarding 2 Maps and a list's state)
- Locks can be passed around outside of a method to be unlocked later (pretty sure that's not a good practice though)

If your application is really big with lot of shared data and you dont want to put annotations in your code you can create your own application TIM with its own versioning which will co-reside with your application code base.

Tushar