有 Java 编程相关的问题?

你可以在下面搜索框中键入要查询的问题!

java EHCache如何实现其事务?

这个问题听起来可能很模糊,但我试图理解EHCache事务能力的一般概念
假设我将EHCache配置为内存缓存,并将其配置为缓存MyObject
如果作为事务的一部分执行,EHCache是否克隆我正在检索的MyObject的实例

我这样问主要是因为(在对我的question的回答中)有人建议我使用EHCache,我担心它对性能的影响MyObject是一个中等重量的对象,我不想不必要地复制它
另外,为了验证,EHCache仅在事务中阻止对对象的写入,对吗

谢谢,
伊泰


共 (1) 个答案

  1. # 1 楼答案

    我认为以下关于JTA支持的文档部分回答了您的大部分问题:

    Using a JTA Cache

    All or nothing

    If a cache is enabled for JTA all operations on it must happen within a transaction context, otherwise a TransactionRequiredException will be thrown.

    Change Visibility

    The isolation level offered in Ehcache JTA is READ_COMMITTED. Ehcache is an XAResource. Full two-phase commit is supported.

    Specifically:

    • All mutating changes to the cache are transactional including put, remove, putWithWriter, removeWithWriter and removeAll.
    • Mutating changes are not visible in the local JVM to or across the cluster until COMMIT has been called.
    • Until then, read such as by cache.get(...) by other transactions will return the old copy. Reads do not block.

    Write-behind and Write-through

    If your XA enabled cache is being used with a writer, write operations will be queued until transaction commit time. Solely a Write-through approach would have its potential XAResource participate in the same transaction. Write-behind, while supported, should probably not be used with an XA transactional Cache, as the operations would never be part of the same transaction. Your writer would also be responsible for obtaining a new transaction...

    Using Write-through with a non XA resource would also work, but there is no guarantee the transaction will succeed after the write operation have been executed successfully. On the other hand, any thrown exception during these write operations would cause the transaction to be rolled back by having UserTransaction.commit() throw a RollbackException.

    关于性能,我不会太担心,除非你的对象的重量达到数百MB。但如果这真的是一个问题,请(一如既往地)进行衡量