|
From: Colin S. <col...@ex...> - 2004-02-10 17:37:06
|
I am still debugging a $%$^%$% issue where Spring tries to close a=20
connection and JBoss says it is unknown.
2004-02-10 12:30:44,900 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
executing flush
2004-02-10 12:30:44,900 DEBUG [net.sf.hibernate.impl.SessionImpl] post fl=
ush
2004-02-10 12:30:44,900 DEBUG=20
[org.springframework.transaction.jta.JtaTransactionManager] Triggering=20
beforeCompletion synchronization
2004-02-10 12:30:44,900 DEBUG=20
[org.springframework.transaction.support.TransactionSynchronizationManage=
r]=20
Removed value [org.springframework.orm.hibernate.SessionHolder@df42ce]=20
for key [net.sf.hibernate.impl.SessionFactoryImpl@1da6868] from thread=20
[TP-Processor2]
2004-02-10 12:30:44,900 DEBUG=20
[org.springframework.transaction.support.TransactionSynchronizationManage=
r]=20
Removed value=20
[org.springframework.jdbc.datasource.ConnectionHolder@52a665] for key=20
[org.jboss.resource.adapter.jdbc.WrapperDataSource@c39410] from thread=20
[TP-Processor2]
2004-02-10 12:30:44,900 INFO =20
[org.jboss.resource.connectionmanager.TxConnectionManager] throwable=20
from unregister connection
java.lang.IllegalStateException: Trying to return an unknown=20
connection2! org.jboss.resource.adapter.jdbc.WrappedConnection@1e94776
at=20
org.jboss.resource.connectionmanager.CachedConnectionManager.unregisterCo=
nnection(CachedConnectionManager.java:330)
at=20
org.jboss.resource.connectionmanager.TxConnectionManager$TxConnectionEven=
tListener.connectionClosed(TxConnectionManager.java:539)
at=20
org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.closeHandle(=
BaseWrapperManagedConnection.java:296)
at=20
org.jboss.resource.adapter.jdbc.WrappedConnection.close(WrappedConnection=
.java:117)
at=20
org.springframework.jdbc.datasource.DataSourceUtils.closeConnectionIfNece=
ssary(DataSourceUtils.java:162)
at=20
org.springframework.jdbc.datasource.DataSourceUtils$ConnectionSynchroniza=
tion.beforeCompletion(DataSourceUtils.java:237)
at=20
org.springframework.transaction.support.AbstractPlatformTransactionManage=
r.triggerBeforeCompletion(AbstractPlatformTransactionManager.java:417)
at=20
org.springframework.transaction.support.AbstractPlatformTransactionManage=
r.commit(AbstractPlatformTransactionManager.java:298)
at=20
org.springframework.transaction.interceptor.TransactionInterceptor.invoke=
(TransactionInterceptor.java:174)
at=20
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(Refl=
ectiveMethodInvocation.java:196)
at=20
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAop=
Proxy.java:135)
at $Proxy142.createBuild(Unknown Source)
at=20
com.whatever.coreserv.services.controller.application.ApplicationControll=
erBean.createBuild(ApplicationControllerBean.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at=20
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java=
:39)
at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at=20
org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(State=
lessSessionContainer.java:683)
at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:185)
at=20
org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(Stateles=
sSessionInstanceInterceptor.java:72)
at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:267)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
at=20
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:19=
1)
at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
at=20
org.jboss.ejb.StatelessSessionContainer.internalInvoke(StatelessSessionCo=
ntainer.java:331)
at org.jboss.ejb.Container.invoke(Container.java:700)
at sun.reflect.GeneratedMethodAccessor96.invoke(Unknown Source)
at=20
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI=
mpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at=20
org.jboss.mx.capability.ReflectedMBeanDispatcher.invoke(ReflectedMBeanDis=
patcher.java:284)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:54=
6)
at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:1=
01)
at=20
org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:90=
)
at=20
org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java=
:46)
at=20
org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:45)
at=20
org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionIn=
terceptor.java:100)
at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:85)
at $Proxy127.createBuild(Unknown Source)
....
2004-02-10 12:30:45,291 DEBUG=20
[org.springframework.transaction.jta.JtaTransactionManager] Triggering=20
afterCompletion synchronization
2004-02-10 12:30:45,291 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
transaction completion
2004-02-10 12:30:45,291 DEBUG=20
[org.springframework.orm.hibernate.SessionFactoryUtils] Closing=20
Hibernate session
2004-02-10 12:30:45,291 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
closing session
2004-02-10 12:30:45,291 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
disconnecting session
2004-02-10 12:30:45,291 DEBUG [net.sf.hibernate.impl.SessionImpl]=20
transaction completion
2004-02-10 12:30:45,291 DEBUG=20
[org.springframework.transaction.support.TransactionSynchronizationManage=
r]=20
Clearing transaction synchronization
My feeling is that this is a JBoss bug of some sort though. It was worse=20
in 3.2.2RC3, happeing in a number of places. When I moved to 3.2.3, it=20
only happened in one spot, among a bunch of code that is essentially=20
similar. My feeling is that it's some sort of race condition in the=20
JBoss transaction code. Certainly, if I look at the wrapped connection=20
and the actual connection, right before we call close() on it, it says=20
it is not closed. Then the close() call causes the error to show up in=20
the log...
Weird stuff...
j=FCrgen h=F6ller [werk3AT] wrote:
>Thanks for testing, Thomas. It's a pity that this approach just works fo=
r JDK 1.4; however, JDKs are easier to upgrade than databases. I've never=
tried it on JDK 1.3, but I did try classes12 with JDK 1.4, and that did =
work (after I've changed our code to read the Oracle constants via reflec=
tion; the constant values differ between classes12 and ojdbc14!). I'm not=
sure why JDK 1.3 causes a problem here.
>=20
>I'm finally gonna release RC1 tonight, so there's still a couple of hour=
s to go if you find any issues :-)
>=20
>Juergen
>=20
>
>________________________________
>
>Von: spr...@li... im Auftrag vo=
n tri...@tr...
>Gesendet: Di 10.02.2004 17:40
>An: spr...@li...
>Betreff: Re: [Springframework-developer] Ready for 1.0 RC1
>
>
>
>I tried the imagedb sample application for Oracle. It works using JDK 1=
.4 and
>the odbcj14.jar jdbc driver for an 8i database. It does not work at all=
using
>JDK 1.3 and classes12.zip/jar. This means that we are limited to JDK 1=
.4 for
>this type functionality with Oracle for now.
>
>Just to clarify the Oracle drivers - there are no particular 8i or 9i jd=
bc
>drivers. They are just labeled based on which database version they are
>distributed with. They should be backwards compatible, and if they are =
not it
>is a bug. (There is even a patch for the driver that came with 8i to fi=
x a
>problem connecting to a 9i database.) The only driver availale for JDK =
1.4 is
>the ojdbc14.jar that comes with 9i. Haven't checked out the 10g drivers=
yet.
>
>I ran into a small problem with the html generated by the application. =
The
>browser did not pick up the end of the <textarea> for the description. =
I added
>a separate closing tag and comitted it to cvs.
>
>Thomas
> =20
>
|
|
From: <jue...@we...> - 2004-02-11 12:45:32
|
Damn, 1.0 RC1 is prepared and ready for upload... but SourceForge is =
currently in "read-only" mode :-(
Juergen
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Tuesday, February 10, 2004 8:30 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Ready for 1.0 RC1
Just did a quick test of dropping in ojdbc14.jar into JBoss, where my=20
app is working ok with the 8i classes12.jar, and JBoss CMP is not happy=20
all of a sudden:
2004-02-10 13:53:28,595 DEBUG=20
[com.opensymphony.workflow.loader.XMLWorkflowFactory] getWorkflow build=20
descriptor=3Dcom.opensymphony.workflow.loader.WorkflowDescriptor@1626c6d
2004-02-10 13:53:28,611 ERROR [org.jboss.ejb.plugins.LogInterceptor]=20
TransactionRolledbackLocalException in method: public abstract=20
java.lang.Long=20
com.opensymphony.workflow.spi.ejb.CurrentStepLocal.getId(), causedBy:
java.lang.ArrayIndexOutOfBoundsException: -90
at oracle.sql.LnxLibThin.lnxnuc(LnxLibThin.java:5744)
at oracle.sql.NUMBER.toInt(NUMBER.java:412)
at=20
oracle.jdbc.dbaccess.DBConversion.NumberBytesToInt(DBConversion.java:2884=
)
at=20
oracle.jdbc.driver.OracleStatement.getIntValue(OracleStatement.java:4489)=
at=20
oracle.jdbc.driver.OracleResultSetImpl.getInt(OracleResultSetImpl.java:53=
6)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil$24.readResult(JDBCUtil.java:876)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCUtil$AbstractPrimitiveReader.get(JDBCU=
til.java:803)
at=20
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadArgu=
mentResults(JDBCAbstractCMPFieldBridge.java:424)
at=20
org.jboss.ejb.plugins.cmp.jdbc.bridge.JDBCAbstractCMPFieldBridge.loadInst=
anceResults(JDBCAbstractCMPFieldBridge.java:373)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEnti=
tyCommand.java:188)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCLoadEntityCommand.execute(JDBCLoadEnti=
tyCommand.java:72)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManag=
er.java:612)
at=20
org.jboss.ejb.plugins.cmp.jdbc.JDBCStoreManager.loadEntity(JDBCStoreManag=
er.java:594)
at=20
org.jboss.ejb.plugins.CMPPersistenceManager.loadEntity(CMPPersistenceMana=
ger.java:381)
at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.loadEnti=
ty(CachedConnectionInterceptor.java:352)
at=20
org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynch=
ronizationInterceptor.java:239)
at=20
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(C=
achedConnectionInterceptor.java:185)
at=20
org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentrance=
Interceptor.java:114)
at=20
org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInte=
rceptor.java:163)
at=20
org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.=
java:89)
at=20
org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInte=
rceptor.java:54)
at=20
org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxIntercep=
tor.java:84)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorC=
MT.java:297)
at=20
org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:128)
at=20
org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java=
:118)
at =
org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:191)
at=20
org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFi=
nderInterceptor.java:122)
at=20
org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:489)
at org.jboss.ejb.Container.invoke(Container.java:700)
at=20
org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invoke(BaseLocalProxyFa=
ctory.java:375)
at =
org.jboss.ejb.plugins.local.EntityProxy.invoke(EntityProxy.java:38)
at $Proxy126.getId(Unknown Source)
This is OsWorkflow EJB based code. All my Spring/Hibernate code is still =
happy though.
So who knows who's at fault here? :-) All I know is I'm staying with=20
the 8i classes12 until we either move to Oracle 9i, or have no more=20
JBoss EJB dependencies....
tri...@tr... wrote:
>I did some more digging and I can get JDK 1.3 and a recent =
classes12.jar to work
>with 8i. Have not tried 9i today, but it should work too.
>
>The reason I said it did not work was that I tested the JDK 1.4 and 1.3 =
with
>different versions of WebLogic. I used WebLogic 6.1 for JDK 1.3 and =
even when I
>added the most recent oracle driver it blew up on
>"oracle.sql.BLOB.getField(DURATION_SESSION)". I started digging some =
more and
>it turns out that the weblogic.jar for 6.1 contains an outdated version =
of the
>oracle.sql.BLOB and oracle.sql.CLOB classes. By putting the latest
>classes12.jar first on the classpath everything works fine.
>
>If I have some time later, I will try 9i as well.
>
>Thomas
>
>
>Quoting Colin Sampaleanu <col...@ex...>:
>
> =20
>
>>I think Thomas is saying that classes12 didn't work with JDK 1.3 with=20
>>8i. It probably works with 9i... Thomas, please correct me if I am =
wrong.
>>
>>
>>j=FCrgen h=F6ller [werk3AT] wrote:
>>
>> =20
>>
>>>Thanks for testing, Thomas. It's a pity that this approach just works =
for
>>> =20
>>>
>>JDK 1.4; however, JDKs are easier to upgrade than databases. I've =
never tried
>>it on JDK 1.3, but I did try classes12 with JDK 1.4, and that did work =
(after
>>I've changed our code to read the Oracle constants via reflection; the
>>constant values differ between classes12 and ojdbc14!). I'm not sure =
why JDK
>>1.3 causes a problem here.
>> =20
>>
>>>I'm finally gonna release RC1 tonight, so there's still a couple of =
hours to
>>> =20
>>>
>>go if you find any issues :-)
>> =20
>>
>>>Juergen
>>>
>>>
>>>________________________________
>>>
>>>Von: spr...@li... im Auftrag =
von
>>> =20
>>>
>>tri...@tr...
>> =20
>>
>>>Gesendet: Di 10.02.2004 17:40
>>>An: spr...@li...
>>> =20
>>>
>
> =20
>
>>>Betreff: Re: [Springframework-developer] Ready for 1.0 RC1
>>>
>>>
>>>
>>>I tried the imagedb sample application for Oracle. It works using =
JDK 1.4
>>> =20
>>>
>>and
>> =20
>>
>>>the odbcj14.jar jdbc driver for an 8i database. It does not work at =
all
>>> =20
>>>
>>using
>> =20
>>
>>>JDK 1.3 and classes12.zip/jar. This means that we are limited to =
JDK 1.4
>>> =20
>>>
>>for
>> =20
>>
>>>this type functionality with Oracle for now.
>>>
>>>Just to clarify the Oracle drivers - there are no particular 8i or 9i =
jdbc
>>>drivers. They are just labeled based on which database version they =
are
>>>distributed with. They should be backwards compatible, and if they =
are not
>>> =20
>>>
>>it
>> =20
>>
>>>is a bug. (There is even a patch for the driver that came with 8i to =
fix a
>>>problem connecting to a 9i database.) The only driver availale for =
JDK 1.4
>>> =20
>>>
>>is
>> =20
>>
>>>the ojdbc14.jar that comes with 9i. Haven't checked out the 10g =
drivers
>>> =20
>>>
>>yet.
>> =20
>>
>>>I ran into a small problem with the html generated by the =
application. The
>>>browser did not pick up the end of the <textarea> for the =
description. I
>>> =20
>>>
>>added
>> =20
>>
>>>a separate closing tag and comitted it to cvs.
>>>
>>>Thomas
>>>=20
>>>
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer
|
|
From: Alef A. <al...@jt...> - 2004-02-04 23:25:23
|
There's an issue that just came up with the TransactionManager. I haven't spend enough time on it to fully figure it out, but before I dig into it further, maybe you guys can give an opinion: When using a DataSourceTransactionManager, in a bean I'm asking the applicationcontext for the transactionmanager. After calling setRollbackOnly() is doesn't rollback. I've reproduced this using petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic and in one of the store*** methods calling: PlatformTransactionManager mgr = (PlatformTransactionManager)appCtx.getBean( "transactionManager"); // does this give me the current transaction??? mgr.getTransaction(null).setRollbackOnly(); AFAIK this should result in a rollback, shouldn't it... Thanx, Alef P.s. we're doing this because of some legacy code that needs to rollback as well. We can't reimplement it right now... |
|
From: Colin S. <col...@ex...> - 2004-02-05 00:09:00
|
The current transaction is just attached to the Thread via the DataSource. The lowest-hanging fruit is to first of all step through the getTransaction call in AbstractPlatformTransactionManager and verify that in fact you are getting back the current transaction off the current thread. In the case of feeding it the null TransactionDefinition, the code path is very simple, so I doubt that is where it's failing, but you can verify. If that is ok, step through the commit call and see if it's actually getting the same TransactionStatus object it created before, and it has the rollback flag on like it should... > <pre wrap>There's an issue that just came up with the > TransactionManager. I > haven't spend enough time on it to fully figure it out, but before I dig > into it further, maybe you guys can give an opinion: > > When using a DataSourceTransactionManager, in a bean I'm asking the > applicationcontext for the transactionmanager. After calling > setRollbackOnly() is doesn't rollback. I've reproduced this using > petclinic, by implementing ApplicationContextAware in AbstractJdbcClinic > and in one of the store*** methods calling: > > PlatformTransactionManager mgr = > (PlatformTransactionManager)appCtx.getBean( > "transactionManager"); > // does this give me the current transaction??? > mgr.getTransaction(null).setRollbackOnly(); > > AFAIK this should result in a rollback, shouldn't it... > > Thanx, > > Alef > > P.s. we're doing this because of some legacy code that needs to rollback > as well. We can't reimplement it right now... |