Can I use synchronized block inside EJB for accessing a non-ejb related Collection?

[Robert Paris]

I know the spec says you can't use the word synchronized, but is that just on EJB objects/methods? Can I have something like:

 
...inside some method in a bean...
List synchedList = ( List ) externalJNDI.lookup( "synchedList" );
synchronized ( synchedList )
{
    //do something to that list
}

The list is not managed by the container, and it has no EJBs in it. Can I use synchronized on it while iterating through it and adding to it?

[Valentin Tanase]

Hi Robert,

Generally speaking is better to use the synchronizedCollection() method of the Collections class:

List myList = ( List ) externalJNDI.lookup( "synchedList" );
SynchedList = Collections.synchronizedCollection(myList);

However, generally speaking I really like the topic you�ve suggested: can developer synchronize the code inside of ejbs? My answer would be better avoid it, but it could be acceptable if requirements prove it necessary. There are other similar topics, like using singletons with ejbs that are also not recommended, but they still could be valuable assets in a j2ee design. What I�m trying to say I believe is that the specs have a lot of value, but practice also proved that sometimes going beyond the specs is not that bad either. What do you think?
Regards.

[Robert Paris]

Generally speaking is better to use the synchronizedCollection() method of the Collections class:

List myList = ( List ) externalJNDI.lookup( "synchedList" );
SynchedList = Collections.synchronizedCollection(myList);

But that's what I did. The Java API JavaDocs say:

Collections.synchronizedCollection(...) returns a synchronized (thread-safe) list 
backed by the specified list. In order to guarantee serial access, it is critical that all 
access to the backing list is accomplished through the returned list.
 
It is imperative that the user manually synchronize on the returned list when iterating over it: 
 
  List list = Collections.synchronizedList(new ArrayList());
      ...
  synchronized(list) {
      Iterator i = list.iterator(); // Must be in synchronized block
      while (i.hasNext())
          foo(i.next());
  }
 
Failure to follow this advice may result in non-deterministic behavior. 

[ May 11, 2005: Message edited by: Robert Paris ]

[Valentin Tanase]

List synchedList = ( List ) externalJNDI.lookup( "synchedList" );
synchronized ( synchedList )
{
//do something to that list
}

Sorry but your initial posting didn�t make this very clear, or at least it wasn�t very clear to me. Initially I thought that you only want to synchronize the basic add/remove/get operations.
However the real question is whether synchronized block of code might be allowed or not with ejbs. My opinion again is that in certain situation it might be allowed if there aren�t other solutions. Couple of examples could be using the Hashtable and Vector classes (which as far as I know j2ee doesn�t forbid them), or synchronizing the getInstance() method when implementing singletons (which again arguable might be considered "bad practice").
Other opinions?

[Robert Paris]

However the real question is whether synchronized block of code might be allowed or not with ejbs.

Sort of, the question is more: with JNDI, can an object obtained through jndi.lookup be protected by locks even if accessed from diff. JVMs?

[Valentin Tanase]

with JNDI, can an object obtained through jndi.lookup be protected by locks even if accessed from diff. JVMs?

I would say that depends whether the object is an rmi object or a custom object. For rmi objects, the rule is the one you might expect: a client accesses the real object through stubs and is the object�s responsibility to synchronize the data access (or server�s responsibilities if the rmi object happens to be an ejb). Hence proper synchronization will guarantee the data integrity even if the object is access from diff jvms.
For non rmi objects the story is little bit different because what the clients get is not a stub, but the object itself. Therefore every standalone client will have a copy of the same object and no synchronization is needed. The problem will rise when a client changes its local copy and needs to rebound it to the jndi tree in order to save the changes. The problem will look like synchronizing the access to the jndi tree itself and this might be not very trivial to solve.
Another interesting topic about binding custom objects to jndi tree is related to a clustered environment: would the object be available for each server instance in the cluster? But this is another story�
Regards.