On Dec 14, 2012, at 2:30 PM, "Howard W. Smith, Jr." <smithh032...@gmail.com>
wrote:
> I will let you know, if I use Singleton and @Lock(WRITE). On the current
> database (Apache Derby), the @Lock(WRITE) always results in a 'locked'
> exception which tells me that @Lock(WRITE) does not work well with the
> Apache Derby database.
>
> It would be nice to know why all you recommended to me...does not work with
> Apache Derby;
Looks like you got it working, which is fantastic!
Just as an FYI to make sure no false lessons are learned, the @javax.ejb.Lock
annotation only affects access to the @Singleton. Under the covers the @Lock
is really just syntactic sugar for a ReentrantReadWriteLock[1]. The container
creates one for every @Singleton class and only the container can see it or use
it. Before letting a call reach the Singleton, the container effectively
invokes:
theSingletonInstancesLock.readLock().tryLock(accessTimeout.time(),
accessTimeout.unit())
Where `theSingletonInstancesLock` is a simple private final variable held by a
private scoped class (to really ensure no one else can use it). The
@Lock(WRITE) is a synonym for `writeLock()` and `@Lock(READ)` is a synonym for
`readLock()`. The accessTimeout.time()/unit() are supplied via a
@javax.ejb.AccessTimeout annotation on the method or bean class.
In short, not at all related to Derby's locking. If there were issues, it
mgiht have been correlated but definitely not caused by it -- not in a direct
sense.
-David
[1]
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html
