[JSR308] Concurrency annotations on blocks

[Eugene Kuleshov]

Tom Ball wrote:
>>  I am not making this up and these tools already exist on the marked 
>> (JBoss Cache, Terracotta), but they are suffering from the 
>> limitations of the current metadata facility and have to workaround 
>> those limitations.
> I would love to hear directly from those developers as to their 
> specific issues, as it sounds like their input would be very pertinent 
> to this discussion.  Would you invite them to join this alias?
  Tom, I am sorry about confusion. I'll forward this to my colleagues at 
Terracotta for more formal response. I am acting here as an individual 
but I do work for Terracotta and quite familiar with the use cases.

  For those who don't know about Terracotta [1], its core product DSO 
(Distributed Shared Objects) it is a runtime environment that takes 
regular Java applications and allows to run them in a distributed 
environment. Those applications don't have to be written for the 
clustered environment and don't even have to use any proprietary API, 
but in many cases single-node multithreaded applications can be 
declaratively clustered with DSO [2].

  For example, under DSO, all synchronization primitives, including 
synchronized blocks, concurrent locks, wait/notify calls can be 
propagated to the entire cluster and it all done in a declarative way. 
Another example similar to regular Java event notification, is the 
distributed method calls, when call is broadcasted to nodes that hold 
instance of the distributed object.

  Unfortunately right now, those declarations has to stay outside of the 
source code, which can be inconvenient to the users and require to use 
special domain language to link them back to the actual code, which not 
look very natural to the end users.

  Being a runtime environment also opens very attractive possibilities 
to make certain decisions at the execution time (similar to JIT or 
Hotspot optimizations). For instance, if certain code should be executed 
on the current node, or should id be transparently moved to the other 
node that has the data that need to be processed. I am not saying that 
is already implemented, but it is being actively investigated.

  regards,
  Eugene

[1] http://terracotta.org/
[2] http://terracotta.org/confluence/display/devdocs/Architecture