[Hibernate-JIRA] Commented: (HHH-1794) HQL query (list) that SELECTs instances mixed with scalars returns NULLs (instance mappings are in a one-to-one relation)
by anuj (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1794?page=c... ]
anuj commented on HHH-1794:
---------------------------
The same issue still appears is also true in Hibernate 3.2.3.
select a, a.B, 'Some scalar' from A a" returns NULL for b.
> HQL query (list) that SELECTs instances mixed with scalars returns NULLs (instance mappings are in a one-to-one relation)
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: HHH-1794
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1794
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1.3
> Environment: Hibernate 3.1.3
> Postgres 8.1.2
> Java 1.5.0_06
> Reporter: Conor Tee
> Attachments: hibernate-scalar-problem.tar.gz
>
>
> Given that "a" is a table whose id is reflected in table "b" as a PRIMARY FOREIGN KEY.
> Mapping a->b and b->a with the appropriate "one-to-one" mappings (I hope), then
> "select a, b from A a join a.b b"
> returns "a" and "b" instances correctly..
> However: (this is where I see the problem)
> "select a, b, 'Some scalar' from A a join a.b b" or "select a, a.B, 'Some scalar' from A a"
> returns "a" and the "scalar" correctly, but returns NULL for b!
> Attached is a working example with a README, Postgres schema build script and ant "build & run" script
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[Hibernate-JIRA] Commented: (HHH-1296) Non lazy loaded List updates done in wrong order, cause exception
by Jeff Zarnett (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c... ]
Jeff Zarnett commented on HHH-1296:
-----------------------------------
Nigel has correctly and fully outlined the problem, so it is not necessary for me to repeat it. I have made the change that removes the unique constraint and leads to success in the attached test cases.
Two files are now attached to this issue. The larger of the two is unicode and the smaller is ANSI, but their contents are the same. They contain the (quite small) diff to resolve the issue.
> Non lazy loaded List updates done in wrong order, cause exception
> -----------------------------------------------------------------
>
> Key: HHH-1296
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 & 5, db2 v8)
> NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is not allowed.
> Reporter: David Birch
> Priority: Critical
> Attachments: listupdate_patch.txt, listupdate_patch.txt, listupdate_testcase.zip
>
>
> The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA who won't let up...)
> The scenario is:
> a bean with list property, and the list has a number of items in it (say 4, index 0-3), an item is then removed (say item at index 2), and the bean is requested to be saved.
> From what i can see in the SQL traces, the same statements are issues whe lazy loading is on or off, they are:
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY set POLICY_NK=? where CLIENT_ID=? and POSITION=?
> So, i can only assume (as when this fails, the row with index 1 above the removed row is nuked!), hibernate removes the item at index 3, and then copies the value of the item at index 3 onto the row for item at index 2. Fair enough but...
> When i have lazy loading off, i get DB exceptions like
> Duplicate key or integrity constraint violation message from server: "Duplicate entry '1-999999' for key 1"
> so, there is some nasty in there, which is not updating the correct row - this has happened since 2.1.8 that i know of :(
> i will try & look @ the source, but won't get a chance until after xmas...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[Hibernate-JIRA] Updated: (HHH-1296) Non lazy loaded List updates done in wrong order, cause exception
by Jeff Zarnett (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c... ]
Jeff Zarnett updated HHH-1296:
------------------------------
Attachment: listupdate_patch.txt
The previous file was unicode encoded and that presents some problems. This one is in ANSI format.
> Non lazy loaded List updates done in wrong order, cause exception
> -----------------------------------------------------------------
>
> Key: HHH-1296
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 & 5, db2 v8)
> NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is not allowed.
> Reporter: David Birch
> Priority: Critical
> Attachments: listupdate_patch.txt, listupdate_patch.txt, listupdate_testcase.zip
>
>
> The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA who won't let up...)
> The scenario is:
> a bean with list property, and the list has a number of items in it (say 4, index 0-3), an item is then removed (say item at index 2), and the bean is requested to be saved.
> From what i can see in the SQL traces, the same statements are issues whe lazy loading is on or off, they are:
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY set POLICY_NK=? where CLIENT_ID=? and POSITION=?
> So, i can only assume (as when this fails, the row with index 1 above the removed row is nuked!), hibernate removes the item at index 3, and then copies the value of the item at index 3 onto the row for item at index 2. Fair enough but...
> When i have lazy loading off, i get DB exceptions like
> Duplicate key or integrity constraint violation message from server: "Duplicate entry '1-999999' for key 1"
> so, there is some nasty in there, which is not updating the correct row - this has happened since 2.1.8 that i know of :(
> i will try & look @ the source, but won't get a chance until after xmas...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[Hibernate-JIRA] Updated: (HHH-1296) Non lazy loaded List updates done in wrong order, cause exception
by Jeff Zarnett (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c... ]
Jeff Zarnett updated HHH-1296:
------------------------------
Attachment: listupdate_patch.txt
SVN Diff file containing the change to resolve the unique key constraint.
> Non lazy loaded List updates done in wrong order, cause exception
> -----------------------------------------------------------------
>
> Key: HHH-1296
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 & 5, db2 v8)
> NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is not allowed.
> Reporter: David Birch
> Priority: Critical
> Attachments: listupdate_patch.txt, listupdate_testcase.zip
>
>
> The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA who won't let up...)
> The scenario is:
> a bean with list property, and the list has a number of items in it (say 4, index 0-3), an item is then removed (say item at index 2), and the bean is requested to be saved.
> From what i can see in the SQL traces, the same statements are issues whe lazy loading is on or off, they are:
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY set POLICY_NK=? where CLIENT_ID=? and POSITION=?
> So, i can only assume (as when this fails, the row with index 1 above the removed row is nuked!), hibernate removes the item at index 3, and then copies the value of the item at index 3 onto the row for item at index 2. Fair enough but...
> When i have lazy loading off, i get DB exceptions like
> Duplicate key or integrity constraint violation message from server: "Duplicate entry '1-999999' for key 1"
> so, there is some nasty in there, which is not updating the correct row - this has happened since 2.1.8 that i know of :(
> i will try & look @ the source, but won't get a chance until after xmas...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[Hibernate-JIRA] Commented: (HHH-1524) Error on left outer join with Oracle Dialect: ORA-00936: missing expression
by Konstantin Skabeev (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1524?page=c... ]
Konstantin Skabeev commented on HHH-1524:
-----------------------------------------
While the patch fixes placing of (+) around the operators (thank you, Milosz), the addLeftOuterJoinCondition() method doesn't take into consideration the queries with OR or IN operators resulting in the following error: "ORA-01719: outer join operator (+) not allowed in operand of OR or IN". In addition, this method doesn't care about the operand and places (+) after the first one (e.g. ... where 1(+) = ...), which makes some sql invalid.
BTW, in my case this happens when either a where attribute is specified or a filter is applied to a <set>. If the specified condition is complex enough (i.e. includes subselect), it will also fail using Oracle9Dialect as it can't left outer join on subselect. I guess, this is a separate issue/bug.
Thanks,
Konstantin.
> Error on left outer join with Oracle Dialect: ORA-00936: missing expression
> ---------------------------------------------------------------------------
>
> Key: HHH-1524
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1524
> Project: Hibernate3
> Issue Type: Bug
> Components: query-sql
> Affects Versions: 3.1.2
> Environment: Oracle 8.1.7, Hibernate 3.1.2
> Reporter: Marcelo Oliveira
> Priority: Critical
> Attachments: HHH-1524.patch, ORA-00936.zip, SUP-3701.zip
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> With this HQL:
> from Company comp
> left outer join comp.employees empl
> with empl.birthday > :date
> Produce following SQL:
> select
> company0_.id as id0_0_,
> employees1_.id as id1_1_,
> company0_.companyName as companyN2_0_0_,
> employees1_.name as name1_1_,
> employees1_.birthday as birthday1_1_,
> employees1_.companyId as companyId1_1_
> from
> TB_COMPANY_TEMP company0_,
> TB_EMPLOYEE_TEMP employees1_
> where
> company0_.id=employees1_.companyId(+)
> and (employees1_.birthday(+)>(+)=?)
> When it is run, the stacktrace is:
> org.hibernate.exception.SQLGrammarException: could not execute query
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:65)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.doList(Loader.java:2148)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
> at org.hibernate.loader.Loader.list(Loader.java:2024)
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
> at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
> at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1129)
> at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
> at mytest.OuterJoinTest.main(OuterJoinTest.java:28)
> Caused by: java.sql.SQLException: ORA-00936: missing expression
> at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
> at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:643)
> at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1674)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1870)
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:314)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> at org.hibernate.loader.Loader.doList(Loader.java:2145)
> ... 8 more
> The correct where clause should be :
> where
> company0_.id=employees1_.companyId(+)
> and (employees1_.birthday(+)>=?)
> This error don't occur with MySQLDialect or SQLServerDialect. Probably it considers >= as two operators instead of a single operator.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[Hibernate-JIRA] Created: (HHH-2632) Illegal JNDI lookup of java:comp/websphere/ExtendedJTATransaction in beforeCompletion method in WebSphere 6.1.0.5
by Chris Rose (JIRA)
Illegal JNDI lookup of java:comp/websphere/ExtendedJTATransaction in beforeCompletion method in WebSphere 6.1.0.5
-----------------------------------------------------------------------------------------------------------------
Key: HHH-2632
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2632
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1, 3.2.3
Environment: WebSphere application server 6.1.0.5
Hibernate 3.2.4sp1 and 3.2.3
Oracle 9i
Reporter: Chris Rose
Attachments: hibernate_issue.was61.log, WebSphereExtendedJTATransactionLookup.java
Hibernate's WebSphere JTA lookup class is performing an illegal JNDI lookup during the beforeCompletion method call in the SynchronizationCallback handler on WebSphere 6.1
WebSphere's own documentation on this at http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/topic/com.ibm.websp... indicates that beforeCompletion and afterCompletion should not make JNDI calls in the java: namespace, which means that the lookup for the ExtendedJTATransaction is not a legal operation.
In the trace below you'll see a replacement WebSphereExtendedJTATransactionLookup class (source code attached to this report) that attempted to get around this by lazily loading the ExtendedJTATransaction reference on demand, but that doesn't solve the problem. Note that the behaviour of the class is not affected by this change, it just looks up the reference on demand instead of during construction.
I'm not sure what the correct solution is; there doesn't seem to be a time in the lifecycle of the transaction manager where the ExtendedJTATransaction could be cached, but that's the obvious requirement.
Stack trace follows:
[5/23/07 17:09:19:877 GMT-07:00] 00000025 javaURLContex E NMSV0310E: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. Exception stack trace:
javax.naming.ConfigurationException [Root exception is javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:204)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:144)
at javax.naming.InitialContext.lookup(InitialContext.java:363)
at com.aciworldwide.ecourier.utility.hibernate.extensions.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.getExtendedJTATransaction(WebSphereExtendedJTATransactionLookup.java:126)
at com.aciworldwide.ecourier.utility.hibernate.extensions.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.getLocalId(WebSphereExtendedJTATransactionLookup.java:191)
at com.aciworldwide.ecourier.utility.hibernate.extensions.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.getStatus(WebSphereExtendedJTATransactionLookup.java:216)
at org.hibernate.util.JTAHelper.isTransactionInProgress(JTAHelper.java:44)
at org.hibernate.transaction.CMTTransactionFactory.isTransactionInProgress(CMTTransactionFactory.java:47)
at org.hibernate.jdbc.JDBCContext.isTransactionInProgress(JDBCContext.java:187)
at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:240)
at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:181)
at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:121)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:187)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:172)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:94)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:507)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:499)
at org.hibernate.engine.CascadingAction$1.cascade(CascadingAction.java:218)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:268)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:216)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascadeCollectionElements(Cascade.java:296)
at org.hibernate.engine.Cascade.cascadeCollection(Cascade.java:242)
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:219)
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:169)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:131)
at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:122)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:65)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59)
at com.aciworldwide.ecourier.utility.hibernate.extensions.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter$1.invoke(WebSphereExtendedJTATransactionLookup.java:151)
at $Proxy4.beforeCompletion(Unknown Source)
at com.ibm.ws.jtaextensions.SynchronizationCallbackWrapper.beforeCompletion(SynchronizationCallbackWrapper.java:65)
at com.ibm.ws.Transaction.JTA.RegisteredSyncs.distributeBefore(RegisteredSyncs.java:240)
at com.ibm.ws.Transaction.JTA.TransactionImpl.prePrepare(TransactionImpl.java:2373)
at com.ibm.ws.Transaction.JTA.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:1606)
at com.ibm.ws.Transaction.JTA.TransactionImpl.processCommit(TransactionImpl.java:1577)
at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java:1512)
at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java:237)
at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java:162)
at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:756)
at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:181)
at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:581)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3893)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3715)
at com.aciworldwide.ecourier.management.ejb.remote.EJSRemoteStatelessDocumentManager_dff32e35.addTrackingEvent(Unknown Source)
at com.aciworldwide.ecourier.management.ejb.remote._EJSRemoteStatelessDocumentManager_dff32e35_Tie.addTrackingEvent(_EJSRemoteStatelessDocumentManager_dff32e35_Tie.java:228)
at com.aciworldwide.ecourier.management.ejb.remote._EJSRemoteStatelessDocumentManager_dff32e35_Tie._invoke(_EJSRemoteStatelessDocumentManager_dff32e35_Tie.java:119)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:613)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:466)
at com.ibm.rmi.iiop.ORB.process(ORB.java:503)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1552)
at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2673)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2551)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:62)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469)
Caused by: javax.naming.NameNotFoundException: Name comp/websphere not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.getParentCtxInternal(NameSpace.java:1767)
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1083)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:991)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1263)
at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:384)
... 61 more
[5/23/07 17:09:19:884 GMT-07:00] 00000025 RegisteredSyn E WTRN0074E: Exception caught from before_completion synchronization operation: java.lang.UnsupportedOperationException
at com.aciworldwide.ecourier.utility.hibernate.extensions.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.setRollbackOnly(WebSphereExtendedJTATransactionLookup.java:226)
at org.hibernate.transaction.CacheSynchronization.setRollbackOnly(CacheSynchronization.java:73)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:63)
at com.aciworldwide.ecourier.utility.hibernate.extensions.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter$1.invoke(WebSphereExtendedJTATransactionLookup.java:151)
at $Proxy4.beforeCompletion(Unknown Source)
at com.ibm.ws.jtaextensions.SynchronizationCallbackWrapper.beforeCompletion(SynchronizationCallbackWrapper.java:65)
at com.ibm.ws.Transaction.JTA.RegisteredSyncs.distributeBefore(RegisteredSyncs.java:240)
at com.ibm.ws.Transaction.JTA.TransactionImpl.prePrepare(TransactionImpl.java:2373)
at com.ibm.ws.Transaction.JTA.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:1606)
at com.ibm.ws.Transaction.JTA.TransactionImpl.processCommit(TransactionImpl.java:1577)
at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java:1512)
at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java:237)
at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java:162)
at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:756)
at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:181)
at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:581)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3893)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3715)
at com.aciworldwide.ecourier.management.ejb.remote.EJSRemoteStatelessDocumentManager_dff32e35.addTrackingEvent(Unknown Source)
at com.aciworldwide.ecourier.management.ejb.remote._EJSRemoteStatelessDocumentManager_dff32e35_Tie.addTrackingEvent(_EJSRemoteStatelessDocumentManager_dff32e35_Tie.java:228)
at com.aciworldwide.ecourier.management.ejb.remote._EJSRemoteStatelessDocumentManager_dff32e35_Tie._invoke(_EJSRemoteStatelessDocumentManager_dff32e35_Tie.java:119)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:613)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:466)
at com.ibm.rmi.iiop.ORB.process(ORB.java:503)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1552)
at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2673)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2551)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:62)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1469)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months
[Hibernate-JIRA] Created: (HHH-2634) PersistentSet.contains() and remove() do not work as expected
by Albert Zheng (JIRA)
PersistentSet.contains() and remove() do not work as expected
-------------------------------------------------------------
Key: HHH-2634
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2634
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.1
Environment: 3.2.1
Reporter: Albert Zheng
Scenario is as following:
class P {
private Set<C> children;
...
}
class C {
private long id;
public int hashCode() {
return id;
}
}
class C's id is generated with id generator and C.hashCode() method uses its id for calculation.
Session session = sf.openSession();
P p = session.load(P.class, id);
C c = new C();
p.getChildren().add(c);
session.saveOrUpdate(p); //cascade is all, so c will be inserted into db
System.out.println(p.getChildren().contains(c)); //this method will return false
p.getChildren() is a PersistentSet, it has an internal HashSet to contain the object. When p.getChildren().add(c) is called, the HashSet put c into hash bucket with hashCode 0. After c is inserted into db, hibernate assigns a generated id for c, p.getChildren().contains(c) uses another hashCode to find c in the HashSet. Of course, this search will fail.
I think Hibernate should re-construct the HashSet after persistenting a dirty PersistentSet.
Also refer http://forum.hibernate.org/viewtopic.php?t=965543 for the issue discussion.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 7 months