分布式锁定和 Java EE

发布于 2024-10-27 13:01:43 字数 1055 浏览 1 评论 0原文

我正在使用 JBoss AS 6 编写一个 Java EE 应用程序,并且我有一个资源需要对给定参数的方法进行独占访问(第三方软件位的某些接口)。目前我很顽皮(因为 ​​规范禁止它)并使用java.util.concurrent.ReentrantLock 来处理锁定。

现在,我将多个 JBoss 应用程序服务器集群在一起,因此我需要一个可以跨集群中不同节点工作的解决方案。我想我至少有以下几个选择。

  1. 共享缓存 (Infinispan)
  2. JGroups
  3. 基于文件系统的锁定(可能不好,但无论如何我们都依赖共享文件系统)
  4. 数据库
  5. Singleton EJB

理想情况下,我正在寻找一个高级 API,以便我可以编写像这样的 EJB 方法

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();
        }
    }

我是否错过了任何选项?有谁有这种锁定机制的经验可以分享吗?

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 share?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

相对绾红妆 2024-11-03 13:01:43

理想情况下,我建议将第三方软件包装到仅在单个实例上运行的单独应用程序中。通过这种方式,您可以使用 EJB 单例来处理锁定(我相信 @Singleton 在您的场景中不会为您提供帮助)并使用远程 EJB/WS 公开它。看起来这个软件有点令人讨厌(单线程?),所以拥有更用户友好的 EJB 界面将是一个额外的好处。

想想看 - 如果整个系统一次只能访问该库一次,为什么还要麻烦分发它呢?无论如何,始终最多有一个实例能够使用。

如果您想坚持使用同构分布式系统(这通常不是一个坏主意),我建议使用SELECT FOR UPDATE进行数据库锁定。我从未尝试过,但我认为在使用库之前发出这样的 SQL(获取锁)并让 EJB 容器随后提交事务(有效释放锁)就可以解决问题。

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.

远昼 2024-11-03 13:01:43

使用 http://hadoop.apache.org/zookeeper/ 怎么样?
它是分布式系统上的一种非常轻量的文件系统,也是实现锁的良好解决方案。

请参阅:http://hadoop.apache.org/zookeeper/ docs/r3.1.2/recipes.html#sc_outOfTheBox

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

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文