带应用引擎的EclipseLink JPA：缓存同步

Question

我有一个应用引擎项目，使用EclipseLink作为JPA持久性管理器，将数据持久化到云SQL实例中。

由于应用程序引擎（多实例环境）的性质，我们对如何在实例之间同步JPA缓存有一些担忧。

每个JPA实例在单个应用引擎实例中运行，因此不使用应用引擎的Memcache服务（否则，EclipseLink不“知道”什么是应用引擎Memcache或如何使用它）

下面是一个简单的场景示例：

- Instance A read object 1: value="A"
- Instance B read object 1: value="A"

- Instance A write object 1: value="B"
- JPA cache of Instance A is evicted due to write operation

- Instance A read object 1: value="B" (the value is retrieved from the database because cache has been evicted after write operation)
- Instance B read object 1: value="A" (no write operation has been performed, the cache is still valid so the value has not been updated)

在四处搜索这种行为时，我发现了不同的文章讨论了这种行为[1][2][3][4]。

我引用：

除非数据库被其他应用程序直接修改，或者被集群环境中其他服务器上的同一应用程序修改

由于App Engine的性质，为此我们可以将其视为“集群环境中的其他服务器”，因此情况似乎就是这样。

当然，处理这个问题的正确方法应该是为JPA构建一个缓存层，该缓存层构建在App Engine memcache服务之上，但从我的搜索中，我了解到EclipseLink不允许开发自定义缓存层。我可以在EclipseLink和App Engine memcache之间搭建一个桥梁，但如果有合适的“挂钩”，我找不到任何参考。

从留档有几个关于如何处理的建议：

>

禁用共享缓存：由于应用程序性能损失，这不是一个合适的选项

使用分布式缓存（如Oracle TopLink Grid with Oracle Coherence）：我想使用App Engine memcache服务，但据我所知，我们不能使用EclipseLink“钩子”

使用缓存协调（同步缓存，如本例所述）提供的方法似乎不适用于App Engine环境

对于如何正确处理这种缓存场景，是否有已知的解决方案？这里的场景非常清楚，当在实例内进行写操作时，需要“通知”所有现有的JPA缓存，以及收回它们自己的缓存。

[1] https://wiki.eclipse.org/EclipseLink/Examples/JPA/CacheCoordination

[2]http://www.eclipse.org/eclipselink/documentation/2.5/concepts/cache011.htm

[3] https://wiki.eclipse.org/EclipseLink/UserGuide/JPA/Basic_JPA_Development/Caching/Coordination

[4] https://wiki.eclipse.org/EclipseLink/Examples/JPA/Caching#Caching_in_Clustered_Environments

Answer 1

我查看了Eclipse Link（EL）源代码，看看是否有任何简单的方法可以扩展缓存协调机制以与GAE一起使用。

EL默认支持JMS和RMI，并且缓存协调是围绕远程处理构建的，因此EL可以发送命令（org.eclipse.persistence.sessions.coordination.Command），这些命令针对AbstractSession在集群中的每个主机上执行。

我认为没有任何方法可以使用MemCache进行缓存，因为像MergeChangeSetCommand这样的命令总是在AbstractSession上运行。

可以通过扩展org来构建自己的缓存协调协议。日食坚持不懈会议。协作TransportManager和设置eclipselink。隐藏物协作协议=com。实例MyTransportManager，但DiscoveryManager使用多播，这在云中通常不可用。如果您可以发现所有GAE实例（并将数据直接发送到每个节点），我认为有可能创建一个基于http的缓存协调解决方案。在AWS上，可以向负载平衡器询问节点列表，这是我们在需要使用Hazelcast进行节点内通信时绕过多播问题的方法。