Re: [JBoss-dev] [Fwd: [JBoss-user] Read-Ahead Cache Supports]
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. -- Scott Stark Chief Technology Officer JBoss Group, LLC 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(TransactionLo cal.java:206) at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.get(TransactionLocal.java:11 8) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.getCache(ReadAheadCa che.java:624) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.add(ReadAheadCache.j ava:570) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache.addFinderResults(ReadAheadCach e.java:114) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbstract QueryCommand.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbstract QueryCommand.java:91) at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFindEntit iesCommand.java:40) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreManage r.java:599) at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistenceManag er.java:324) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntitie 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
Re: [JBoss-dev] [Fwd: [JBoss-user] Read-Ahead Cache Supports]
Alexey, 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. -- Scott Stark Chief Technology Officer JBoss Group, LLC 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
Re[2]: [JBoss-dev] [Fwd: [JBoss-user] Read-Ahead Cache Supports]
Hello Dain, That was me. I switched to TransactionLocal in ReadAheadCache. Before that, just List and Map were used for caching and there were issues with their cleanning which affected subsequent transactions. As the stacktrace shows, the exception occurs right in TransactionLocal.getTransaction(). There is some nice trick needed to not call ReadAheadCache or do nothing in ReadAheadCache when there is no active tx. alex Friday, June 27, 2003, 6:15:39 PM, Dain Sundstrom wrote: DS Alexey, DS Did you make this change or was it me? Either way, I think it is my DS fault as I was the one that re-enabled running with out a transaction DS and didn't add any integration tests. DS -dain DS 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. -- Scott Stark Chief Technology Officer JBoss Group, LLC 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 DS /* DS * Dain Sundstrom DS * Partner DS * Core Developers Network DS */ --- 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
[JBoss-dev] [Fwd: [JBoss-user] Read-Ahead Cache Supports]
So why was this change made? There is a difference between yelling at the user for running under a scenario with potentially n^2 related performance degradation and breaking a working app. -- Scott Stark Chief Technology Officer JBoss Group, LLC 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(TransactionLo cal.java:206) at org.jboss.ejb.plugins.cmp.jdbc.TransactionLocal.get(TransactionLocal.java:11 8) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.getCache(ReadAheadCa che.java:624) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache$ListCache.add(ReadAheadCache.j ava:570) at org.jboss.ejb.plugins.cmp.jdbc.ReadAheadCache.addFinderResults(ReadAheadCach e.java:114) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbstract QueryCommand.java:207) at org.jboss.ejb.plugins.cmp.jdbc.JDBCAbstractQueryCommand.execute(JDBCAbstract QueryCommand.java:91) at org.jboss.ejb.plugins.cmp.jdbc.JDBCFindEntitiesCommand.execute(JDBCFindEntit iesCommand.java:40) at org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.findEntities(JDBCStoreManage r.java:599) at org.jboss.ejb.plugins.CMPPersistenceManager.findEntities(CMPPersistenceManag er.java:324) at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.findEntitie 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
