[
https://issues.jboss.org/browse/ISPN-1047?page=com.atlassian.jira.plugin....
]
Manik Surtani edited comment on ISPN-1047 at 4/18/11 1:18 PM:
--------------------------------------------------------------
This has nothing to do with the XA impl, it has to do with the way read committed
visibility guarantees are maintained in the contexts.
In response to Mircea's comment, transactions have been revisited in 5.0 but this
section (read visibilities and locking) remains the same. So the bug is still relevant
and exists in both 4.2.x and 5.x
was (Author: manik):
This has nothing to do with the XA impl, it has to do with the way read committed
visibility guarantees are maintained in the contexts.
Cache performance slow in a JTA transaction with many cache
operations
----------------------------------------------------------------------
Key: ISPN-1047
URL:
https://issues.jboss.org/browse/ISPN-1047
Project: Infinispan
Issue Type: Quality Risk
Components: Transactions
Affects Versions: 4.2.1.FINAL
Environment: Infinispan 4.2.1.FINAL/Hibernate 3.6.1.Final/Spring 3.0.5/JBossJTA
4.14.0
Reporter: Tom Waterhouse
Assignee: Manik Surtani
Priority: Critical
Labels: performance
Fix For: 4.2.2.BETA1
Attachments: ISPN-1047.zip
When running Infinispan in a JTA transaction the performance of cache operations
decreases as the number of operations increases in the transaction. If adding to the
cache, adding 50k items is much faster when done 1k items per transaction than all 50k in
one transaction.
Using JProfiler the bulk of the time was spent in LockingInterceptor.doAfterCall() for
the all 50k in one transaction test.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira