Did you make this change or was it me? Either way, I think it is my fault as I was the one that re-enabled running with out a transaction and didn't add any integration tests.
-dain
On Friday, June 27, 2003, at 02:07 AM, Alexey Loubyansky wrote:
That was me. I agree, we shouldn't force finders to run under active transaction.
The reason for the change was a bug in cleaning ReadAheadCache. I'll look at it.
alex
Friday, June 27, 2003, 3:11:02 AM, Scott Stark wrote:
SMS> So why was this change made? There is a difference between yelling at
SMS> the user for running under a scenario with potentially n^2 related
SMS> performance degradation and breaking a working app.
-- xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx
-------- Original Message --------
Subject: [JBoss-user] Read-Ahead Cache & Supports
Date: Thu, 26 Jun 2003 15:47:23 -0700
From: Gavin Matthews <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' <[EMAIL PROTECTED]>
CC: Gavin Matthews <[EMAIL PROTECTED]>
All,
I'm upgrading from 3.2.0 to 3.2.2(RC1) and I hit an incompatibility with
the new(?) ReadAheadCache implementation and the finder transaction type.
Basically if I have a finder with transaction-type="Supports" and use
read-ahead-strategy="on-find" then I get the following exception if I'm
outside of a transaction:
14:43:55,968 ERROR [LogInterceptor] RuntimeException:
java.lang.IllegalStateException: There is no tranaction associated with the
current thread
at
org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.getTransaction(Transact ionLo
cal.java:206)
at
org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.get(TransactionLocal.ja va:11
8)
at
org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.getCache(ReadAh eadCa
che.java:624)
at
org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.add(ReadAheadCa che.j
ava:570)
at
org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache.addFinderResults(ReadAhea dCach
e.java:114)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbs tract
QueryCommand.java:207)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbs tract
QueryCommand.java:91)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFind Entit
iesCommand.java:40)
at
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreM anage
r.java:599)
at
org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistence Manag
er.java:324)
at
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEn titie
s(CachedConnectionInterceptor.java:323)
at org.jboss.ejb.EntityContainer.findLocal(EntityContainer.java:604)
The fix for me is trivial, I can switch to transaction-type="Required"
without any issues but I think there is a bug here, the ReadAheadCache
should only be used if you're already in a transaction (the read-ahead cache
strategy is forcing the transaction-type decision which seems wrong to me).
thanks, gavin
-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
/************************* * Dain Sundstrom * Partner * Core Developers Network *************************/
------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
