开发者

Distributed Locking and Java EE

开发者 https://www.devze.com 2023-02-20 12:55 出处:网络
I\'m writing a Java EE application using JBoss AS 6 and I have a resource that requires exclusive access (some interface to a third-party bit of software) to a method for a given parameter.Currently I

I'm writing a Java EE application using JBoss AS 6 and I have a resource that requires exclusive access (some interface to a third-party bit of software) to a method for a given parameter. Currently I'm being naughty (since the specification prohibits it) and using java.util.concurrent.ReentrantLock to handle locking.

Now I'm clustering multiple JBoss application servers together so I need a solution that works across different nodes in the cluster. I think I have at least the following options.

  1. The Shared Cache (Infinispan)
  2. JGroups
  3. File System based locking (probably bad, but we rely on a shared file system anyway)
  4. Database
  5. Singleton EJB's?

Ideally, I'm looking for a high level API so I can write EJB methods like this

public class MyEJBBean {

    private SharedLock lock;

    public void doSomethingWithSharedResource(String s) {
        lock.lock(); // blocks until shared resource is not used by anyone else
        try {
           // Use shared resource
        } 
        finally {
           lock.unlock();
        }
    }

Have I missed any options? Does anyone have any experience with this kind of locking mechanism that they can sha开发者_StackOverflow社区re?


Ideally, I would suggest wrapping the third-party software into a separate application running on just a single instance. This way you can handle locking using EJB singletons (I believe the @Singleton won't help you in your scenario) and expose it using remote EJB/WS. Looks like this piece of software is a bit nasty (single-threaded?) so having more user-friendly EJB interface will be an additional benefit.

Think about it - if you can only access the library once at a time for the whole system, why bother distributing it? Always at most one instance will be able to use anyway.

If you want to stick with homogeneous distributed system (which isn't a bad idea in general), I would suggest database locking using SELECT FOR UPDATE. I never tried it but I think issuing such an SQL before using your library (obtaining a lock) and letting EJB container to commit the transaction (effectively releasing the lock) afterwards will do the trick.


How about using http://hadoop.apache.org/zookeeper/ ? It's a kind of very light file system on distributed systems and good solution for implementing lock.

See this: http://hadoop.apache.org/zookeeper/docs/r3.1.2/recipes.html#sc_outOfTheBox

0

精彩评论

暂无评论...
验证码 换一张
取 消