Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

I have implemented a master worker pattern, where the master is queuing up objects of type Blog, each blog instance has a collection of posts. Each worker thread receives a Blog instance for processing.

Currently my worker threads are blocking on blog.getPosts() (returns the the collection of posts for that blog). I'm guessing I have some kind of mistake in my tc-config file and wondering the following:

How can I tell terracotta that the entries property shouldnt be locking or be shared across the different clusters, since only the worker dealing with the Blog instance cares about the entries collection.

any help much appreciated....

Hi Anonymous,

It's difficult to answer your question w/o at least a copy of the tc-config.xml. Ideally, it would be useful to have a glance at the code. I'll send you a private message with my email. Feel free to forward the information to me at that email address.

Gordon

actually let me slightly rephrase....

What i really want is the posts collection to be transiant to terracotta, but still want the values in the posts collection to be passed to the worker thread, so that they are still accessible but not shared across all the clusters. If I mark the collection as transient, i have to re-query and fetch these values, but if i mark them as shared, they are subject to terracotta locking which i dont want either.

You might be acquiring a write lock if the locks section of your configuration looks like this:

Code:

 <autolock>
   <method-expression>* *..*.*(..)</method-expression>
 </autolock>

which means that a write lock is acquired for every synchronized block of code (if instrumented and shared).

You can change this to a read lock to reduce contention like this:

Code:

 <autolock>
   <method-expression>* package.Blog.getPosts(..)</method-expression>
   <lock-level>read</lock-level>
 </autolock>

Also, even though only the worker dealing with the particular Blog instance is interested in the the posts on that blog, do you know which worker is going to pick up a Blog instance when it is put on the Shared Queue? In other words, if the work is distributed randomly (any worker can pick up any blog), the posts in the blog would also need to be shared so that the appropriate worker also faults in the posts associated with the blog.

Now, if you are confident that once the blog is faulted in (the Blog is picked up by a worker from the queue) no other thread is going to be interested in the posts of that blog, you can use a concurrent lock instead (no contention):

Code:

 <autolock>
   <method-expression>* package.Blog.getPosts(..)</method-expression>
   <lock-level>concurrent</lock-level>
 </autolock>

Lastly, if the posts for a blog are always going to be referenced in the same JVM, you can mark the collection as transient like this:

Code:

 <transient-fields>
         <field-name>package.Blog.posts</field-name>
 </transient-fields>

If a lot of different threads are reading and/or writing individual posts, you might want to consider fine grained locking i.e. synchronize on a post rather than the entire collection of posts (getPost() and setPost() as against getPosts() and setPosts()).

Regards,
Kunal.

great reply, thanks. I think concurrent should do the trick.