与其他应用程序使用相同的DB时JPA的并发性

Question

我正在开发一个Spring MVC JPA Web应用程序.当这个应用程序在实时部署时,我的应用程序与之交互的同一个DB将同时被其他2个Dotnet和VB应用程序使用.我通过版本列管理我的JPA应用程序的并发性.

在同一个数据库中同时运行这3个应用程序时会出现任何问题吗？所有系统都使用相同的表.

我将来必须为同一个DB构建另一个应用程序(最可能是Spring MVC + JPA).在同时运行这两个应用程序时会出现任何问题(在两个应用程序中保持相同的表等)？

Answer 1

访问相同数据库表的多个应用程序可能(通常是)并发噩梦.只是向表中添加版本列没有帮助,因为每个应用程序可能使用不同的并发管理机制.跨应用程序共享数据库时遇到的常见问题(假设所有人的读写访问权限并且没有特定顺序):

1. 并发不匹配:想象一个应用程序使用乐观锁定,另一个使用悲观锁定,第三个使用完全没有锁定(因为所有都由不同的团队维护).即使有一个中央架构小组向每个人分发了良好的应用程序架构建议,开发人员也可以做任何他们喜欢的事情并最终导致并发地狱.
2. 死锁:想象一个应用程序SERIALIZABLE对所有事务使用隔离级别并对数据库执行长时间运行操作,从而导致队列,死锁和超时.即使其他应用程序没有破坏数据,它们最终也可能因死锁和超时而看到太多错误,从而降低了它们的实用性.
3. 数据有效性:开发人员通常使用内存缓存来存储固定或缓慢变化的数据,以节省重复的数据库往返.在由Hibernate支持的JPA应用程序中,开发人员可以使用二级缓存.但是,如果另一个应用程序更新数据库,则缓存将保持陈旧(因此不准确)数据.
4. 数据完整性:不同的应用程序可能使用不同的数据部分.如果允许所有人独立更新公共数据,如何保持参照完整性？业务规则怎么样？它们是否必须在应用程序中重复？
5. 团队沟通开销:每个团队都必须让其他团队了解他们需要对模式进行的更改,以便他们不会踩到彼此的脚趾.如果其他团队不同意团队要求的更改或者优先级无法协调,这甚至可能会降低敏捷性.
6. 架构错误:如果有人删除,重命名,移动或归档应用程序所需的表或列,会发生什么？
7. 访问控制:如果基础数据是敏感的并且需要身份验证和授权,则必须跨应用程序复制访问控制检查.
8. 所有权:由于每个团队可能拥有自己的利益相关者,路线图,约束和优先级,谁拥有公共表变成了挑战.
9. 可移植性:如果某天必须更改底层数据库(供应商和类型),则需要更改所有应用程序.
10. 审计和版本控制:如果需要审计和/或版本化通用数据(多个版本的数据行),则必须跨应用程序复制代码或将代码内置到数据库中(这在数据库中可能并不容易,例如,知道哪个应用程序用户更改了记录).如果在数据库中完成,则可移植性再次受到影响,因为语法可能因数据库供应商而异.
11. 特定于数据库的优化:某些方案(例如,报告)可能需要使用JPA等ORM技术可能无法执行或难以执行的本机查询或其他优化.如果多个应用程序需要访问优化查询,则必须将这些功能构建到数据库(存储过程)中或跨应用程序复制(以可能不同的方式).
12. 归档和分区:不同的应用程序可能具有不同的归档和分区要求.谁能确保每个人的需求得到平等的满足？
13. 标准化:如果允许不同的团队自己管理公共数据库对象,那么数据字典,命名约定等内容如何管理？不同团队使用的表可能具有不同(并且主要是烦人)命名的列,约束等.

更好的方法是使用服务公开公共数据库表.该服务可以始终保持一致和受控制.处理服务变更的常见团队可以确保最大限度地减少意外变更,并及时向所有受影响的各方传达.