[Hibernate-JIRA] Commented: (HHH-1265) classcastexception when using dom4jsession to save xml of a versioned class
by Alan Krueger (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1265?page=c... ]
Alan Krueger commented on HHH-1265:
-----------------------------------
I'm seeing this as well. This has been outstanding for quite a while, is there any chance of this being included in an upcoming release?
> classcastexception when using dom4jsession to save xml of a versioned class
> ---------------------------------------------------------------------------
>
> Key: HHH-1265
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1265
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 beta 2, 3.1
> Environment: hibernate 3.1 oracle windows
> Reporter: Winston Huang
> Attachments: hibernate_test.zip, patches.zip
>
>
> when importing from xml format and trying to save the instance using dom4jsession, i got the following exception. it would succeed if i don't use an optimistic locking object (with versioning). see the attached test case for details. i have a many-to-many set relationship from user to role. the xml data files are in User.xml and Role.xml. loading Role.xml is fine. but loading User.xml failed.
> log4j:WARN No appenders could be found for logger (org.hibernate.cfg.Environment).
> log4j:WARN Please initialize the log4j system properly.
> Exception in thread "main" java.lang.ClassCastException: org.dom4j.tree.DefaultElement
> at org.hibernate.event.def.DirtyCollectionSearchVisitor.processCollection(DirtyCollectionSearchVisitor.java:50)
> at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:104)
> at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java:64)
> at org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(AbstractVisitor.java:58)
> at org.hibernate.event.def.DefaultFlushEntityEventListener.isUpdateNecessary(DefaultFlushEntityEventListener.java:301)
> at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:111)
> at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:190)
> at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:70)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:730)
> at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:329)
> at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:86)
> at TestDom4jVersionedObject.main(TestDom4jVersionedObject.java:26)
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-2698) optimistic-lock="dirty" does not throw StaleObjectException if object modified by another session using detached objects
by Alex McCarrier (JIRA)
optimistic-lock="dirty" does not throw StaleObjectException if object modified by another session using detached objects
------------------------------------------------------------------------------------------------------------------------
Key: HHH-2698
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2698
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.2
Environment: Tomcat 5.5, Hibernate 3.2, Spring 2.0
Reporter: Alex McCarrier
Priority: Minor
We have two clients, a web client and a swing client. With optimistic-lock="dirty" defined for an entity, if two web clients modify the same field on the same entity, it throws StaleObjectException as expected.
We also have a swing client that sends detached entities back and forth. If the detached client modifies and entity at the same time as the web client, no exception is thrown, but the web client fails the update. The reason being is the web client has an extra where clause that includes the modified field, instead of just the primary key. Since the detached client changed the value already, the web client finds nothing to update.
For example, changing description field, web client does something like:
update MyEntity set description = "web description" where id = 1 and description = "old description";
detached client does before web client completes:
update MyEntity where id = 1 set description = "some other description";
web client continues and doesn't find anything to update, because where clause in first query fails.
I would think in this particular scenario, if the web client finds nothing to update, it would throw a StaleObjectStateException.
--
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, 6 months