The problem is concurrent access to the same data from multiple transactions. Since we're using pessimistic locking in JBossCache, some of the transactions will time out trying to acquire locks held by other transactions. Until we implement optimistic locking, here's what you can do to work around this: - Commit the TX after each load(). Essentially a non-solution b/c you're discarding the Hibernate first-level cache every time - Use a different isolation level in JBossCache: instead of REP_READ use READ_UNCOMMITTED. This should be fine when you can accept dirty reads. Otherwise go to READ_COMMITTED.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3863870#3863870 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3863870 ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
