[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3030?page=c...
]
Rishik Dhar commented on HHH-3030:
----------------------------------
Prashant,
What you have done is stopped using the feature of "version" which is used for
optimistic locking at the object level in case of concurrent update on a persistent object
in the ORM session level cache.
By removing the version field, the entity will no longer be managed by the Hibernate for
optimistic locking and will lead to corruption of the state of data in your application.
The change you have made may be okay if a concurrent modification of a persistent object
never happens in your application, i.e. an object is always accessed sequentially by
different transactions within the current session.
However, consider this case, if there are two parallel transactions that need to perform a
read-write operation on the same object, and both of them read the object simultaneously
and update the object, then you transactions will simply ignore the changes made by the
other transaction and try to commit their changes and end up corrupting the state of the
data.
For more information read here:
http://www.redhat.com/docs/manuals/jboss/jboss-eap-4.3/doc/hibernate/Hibe...
You may want to read this before making the change permanent. The only thing that you need
to take care of if you decide to retain the version feature will be introduce the version
column in your tables and set the default value as 0 for the respective entities mapped
with the version property defined in the HBM.
NullPointerException happens in versioning
------------------------------------------
Key: HHH-3030
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3030
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: any
Reporter: John
Priority: Minor
Here is the stack trace:
java.lang.NullPointerException
at org.hibernate.type.IntegerType.next(IntegerType.java:59)
at org.hibernate.engine.Versioning.increment(Versioning.java:25)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.getNextVersion(DefaultFlushEntityEventListener.java:358)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:250)
at
org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:121)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:196)
at
org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76)
at
org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:35)
at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:969)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1114)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
......
The code is:
public Object next(Object current, SessionImplementor session) {
return new Integer( ( (Integer) current ).intValue() + 1 );
}
Should there be a null checking for the object "current"?
--
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