在java中跨多个进程更新单个对象
几个关系数据库表由驻留在进程中的单个对象缓存管理。当提交缓存时，表将被更新。数据库关系表是通过常规 SQL 查询更新的，而不是像 hibernate 这样更奇特的查询。
最终，其他进程开始在不相互通信的情况下修改该对象，即，每个进程都会初始化该对象（从数据库读取）并更新它（提交到数据库），&其他进程不会知道它持有陈旧的缓存。
我必须修复这个工作流程。我想到了几种方法。 一种是让这个对象成为一个 mBean。因此，该对象将驻留在一个进程中，并且每个进程最终都会通过 mBean 方法调用修改该进程中的对象。
然而，这种方法有几个问题。 1) 此缓存返回的每个对象都有一个 mBean，这可能会使方法调用变得非常繁琐。 2）还要求每个进程都应该看到数据库的一致数据模型（缓存），并且如果可能的话，应该将其内容合并到数据库中。 （如交易）。如果数据库被其他进程显着更新，则合并失败是可以接受的。
Java中哪些技术可以帮助解决这个问题？
A couple of Relational DB tables are managed by a single object cache that resides in a process. When the cache is committed the tables are updated. The DB relational tables are updated by regular SQL queries and not anything more fancier like hibernate.
Eventually, other processes got into the business of modifying this object without communicating with one another i.e, Each process would initialize this object (read from DB) and update it( commit to DB), & other process would not know about it holding on to a stale cache.
I have to fix this workflow. I have thought of couple of methods.
One is to make this object an mBean. So, the object would reside on one process and every process would eventually modify the object in that process by mBean method invocations.
However, this approach has a couple of problems.
1) Every object returned by this cache has be an mBean, which could make the method invocations quite chatty.
2) Also there is a requirement that every process should see a consistent data model(cache) of the DB, and it should merge its contents to the DB if possible. (like a transaction). If the DB was updated by some other process significantly, it is OK for the merge to fail.
What technologies in Java will help to solve this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您应该看看 Terracotta。他们拥有使多个 JVM（可以位于不同服务器上）看起来统一的技术。如果您在一个 JVM 上更新对象，Terracotta 将以安全的方式在集群中的所有 JVM 上透明地更新实例。
You should have a look at Terracotta. They have technology that makes multiple JVMs (can be on different servers) appear unified. If you update an object on one JVM, Terracotta will update the instance transparently on all JVMs in the cluster in a safe way.
如果你想保留对象模型，你可以在提交之前使用java对象缓存进行集中存储。或者您可以使用 zookeeper 保持共享锁。
但听起来你真的应该放弃自我管理的缓存。使用 hibernate 或其他 JPA 实现，您提到过。 JPA 解决了缓存问题并维护 L2 共享缓存，因此他们已经为您考虑到了这一点。
If you wanted to keep the object model, you could use java object cache for centralized storage before committing. Or you could keep a shared lock using zookeeper.
But it sounds like you should really abandon the self-managed cache. Use hibernate or another JPA implementation, which you mentioned. JPA addresses the cache issues and maintains a L2 shared cache, so they've thought about this for you.
我同意约翰的观点 - 在休眠中使用二级缓存并支持集群。通过使用简化的数据访问模型来更直接地管理数据，并让 Hibernate 管理细节。
Terracotta Ehcache 就是这样一种缓存，JBoss、Coherence 等也是这样。
有关 Hibernate Second 的更多信息级别缓存可以在此处和中获得Hibernate 官方文档第 19 章提高性能（请注意，虽然 Hibernate 文档确实列出了二级缓存提供程序，但该列表已严重过时，例如谁使用 Swarm Cache？最后一个版本是2003年）
I agree with John - use a second level cache in hibernate with support for clustering. Much more straightforward way to manage data by using a simplified data access model and let Hibernate manage the details.
Terracotta Ehcache is one such cache, so is JBoss, Coherence, etc.
More info on Hibernate Second Level Cache can be had here and in the official Hibernate docs on Chapter 19. Improving Performance (note that the while the Hibernate docs do list second level cache providers, the list is woefully out of date, for example who uses Swarm Cache? The last release of that was in 2003)