[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush
by Josh Moore (JIRA)
many-to-one in a properties element causes strange PropertyValueException on flush
----------------------------------------------------------------------------------
Key: HHH-2075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: HSQLDB
Hibernate r10478
Reporter: Josh Moore
Attachments: exception.txt, log.txt, properties.zip
Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case.
<code>
Image i = new Image();
Pixels p = new Pixels();
p.setSizeC(new Integer(2));
p.setImage(i); // This calls i.getPixels().add(p)
// i.setPixels(null); // This makes it work.
Session s = openSession();
Transaction t = s.beginTransaction();
// s.merge(i); // This makes it work.
p = (Pixels) s.merge(p); // This fails with the exception below.
t.commit();
s.close();
</code>
The properties element in question is:
<code>
<properties name="defaultPixelsTag">
<property name="defaultPixels" type="java.lang.Boolean"/>
<many-to-one name="image" class="Image" column="image"
not-null="true" unique="false" insert="true" update="true"
cascade="lock,merge,persist,replicate,refresh,save-update"
/>
</properties>
</code>
The reverse side is:
<code>
<set
name="pixels"
lazy="true"
inverse="true"
cascade="lock,merge,persist,replicate,refresh,save-update">
<key column="image" not-null="false"/>
<one-to-many class="Pixels"/>
</set>
</code>
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3102) Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
by Paul Cowan (JIRA)
Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
--------------------------------------------------------------------------------
Key: HHH-3102
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3102
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Reporter: Paul Cowan
Priority: Minor
Attachments: HibernateKeyPoolTest.java
Hi all,
Not 100% sure if you'd call this a 'bug' as I'm not sure if the correct behaviour is actually specified anywhere. It's certainly oddly inconsistent though.
Please find attached a standalone test case (requires HSQLDB on the classpath; amend setUp() if you need to use something else) which models a parent-child mapping between 'Mouth' (1) and 'Teeth' (many). The Mouth -> Teeth relationship is bidirectional, with CascadeType.ALL on the single-valued end. Both Mouth and Tooth use a @GenericGenerator, which simply allocates integers from a static keypool.
A mouth with one tooth is created, saveOrUpdate()d, session is flushed, a new tooth is added, mouth is saveOrUpdate()d again, and session is again flushed. The debug output is as follows:
*** After creation
Mouth (id=null) has teeth [canine(id=null)]
*** Save
Mouth (id=1) has teeth [canine(id=2)]
*** Flush
Hibernate: insert into Mouth (id) values (?)
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2)]
*** Add new
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Save again
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Flush again
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2), molar(id=3)]
As you can see, when initially created the IDs for the mouth and tooth are both null (obviously correct). The saveOrUpdate() on the Mouth object then generates identifier values, even though no DB write has been done yet (the .flush()). So far, so good.
However, when a NEW transient Tooth instance ("molar") is added to the Mouth, and saveOrUpdate() is called once more, the id generator is not invoked, UNTIL such time as the session is flushed.
While I guess it's fine for an object in the 'persistent' state not to actually have an identifier until flush-time (e.g. when using DB-side IDENTITY-type generation), it just seems inconsistent that with a @GenericGenerator the behaviour would vary depending on whether the PARENT object was already persistent or not.
There are some obvious workarounds (e.g. flush the session upon saving, or save the child entity first independently) but I thought I'd clarify if this behaviour is by design or not and suggest that this be made consistent.
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-2166) Long "in" lists in queries results in a Java stack overflow exception.
by Philip R. "Pib" Burns (JIRA)
Long "in" lists in queries results in a Java stack overflow exception.
----------------------------------------------------------------------
Key: HHH-2166
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2166
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: Hibernate 3.2.0.cr3 through 3.2.0.ga (at least). Any standard deployment of Sun's JVM on Windows, Linux, or Mac OS X (and presumably other platforms like Solaris)
Reporter: Philip R. "Pib" Burns
Attachments: NodeTraverser.java
With Hibernate 320ga a long "in" list can result in a stack overflow error during the parsing stage. For example, a query element like
where x in (:x)
or a manually constructed
where x in (1,2,3 .....)
can generate a stack overflow if the number of elements referenced by x exceeds a number dependent upon the amount of available stack space. For many JVMs, the limit is between 9,000 and 10,000 assuming a relatively empty stack at the point of query execution. We have applications which occasionally use lists several times this size.
The stack overflow occurs in org.hibernate.hql.ast.util.NodeTraverser which uses a recursive algorithm to walk a parse tree. Long "in" lists generate a subtree of depth about equal to the number of elements in the list. A sufficiently long list results in a stack overflow when NodeTraverser's internal method visitDepthFirst calls itself too many times.
The solution is to replace the recursive tree walking strategy with an iterative one that does not use up stack space. I am attaching the source for a replacement version of . NodeTraverser which implements the iterative tree walking method.
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3850) org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
by wu bin (JIRA)
org.jboss.cache.lock.TimeoutException: failure acquiring lock, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3850
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3850
Project: Hibernate Core
Issue Type: Bug
Components: caching (L2)
Affects Versions: 3.2.6
Environment: linux , oracle 9.2 jboss 4.2.3
Reporter: wu bin
we use hibernate and jboss tree cache in jboss 4.2.3 in lnux.
we only have 1 node in the cluster.
we met this exception:
19:00:58,515 ERROR [TxInterceptor] method invocation failed
org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
19:00:58,516 ERROR [TxInterceptor] prepare method invocation failed
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
... 22 more
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
19:00:58,516 WARN [TreeCache] replication failure with method_call prepare; id:10; Args: ( arg[0] = GlobalTransaction:<16.173.241.57:9242>:119 ...) exception
java.lang.RuntimeException: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:591)
at org.jboss.cache.interceptors.TxInterceptor.handlePessimisticPrepare(TxInterceptor.java:472)
at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:338)
at org.jboss.cache.interceptors.TxInterceptor.invoke(TxInterceptor.java:145)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.CacheMgmtInterceptor.invoke(CacheMgmtInterceptor.java:183)
at org.jboss.cache.TreeCache.invokeMethod(TreeCache.java:5919)
at org.jboss.cache.TreeCache._replicate(TreeCache.java:5196)
at sun.reflect.GeneratedMethodAccessor200.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jgroups.blocks.MethodCall.invoke(MethodCall.java:330)
at org.jgroups.blocks.RpcDispatcher.handle(RpcDispatcher.java:281)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:654)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:544)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:367)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:777)
at org.jgroups.JChannel.up(JChannel.java:1091)
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:382)
at org.jgroups.stack.ProtocolStack.receiveUpEvent(ProtocolStack.java:398)
at org.jgroups.stack.Protocol.passUp(Protocol.java:520)
at org.jgroups.protocols.pbcast.STATE_TRANSFER.up(STATE_TRANSFER.java:158)
at org.jgroups.stack.UpHandler.run(Protocol.java:60)
Caused by: org.jboss.cache.lock.TimeoutException: failure acquiring lock: fqn=/org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT, caller=GlobalTransaction:<16.173.241.57:9242>:119, lock=<unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0)
at org.jboss.cache.Node.acquire(Node.java:533)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.acquireNodeLock(PessimisticLockInterceptor.java:410)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.lock(PessimisticLockInterceptor.java:322)
at org.jboss.cache.interceptors.PessimisticLockInterceptor.invoke(PessimisticLockInterceptor.java:189)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.UnlockInterceptor.invoke(UnlockInterceptor.java:32)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.ReplicationInterceptor.invoke(ReplicationInterceptor.java:39)
at org.jboss.cache.interceptors.Interceptor.invoke(Interceptor.java:68)
at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:568)
... 22 more
Caused by: org.jboss.cache.lock.TimeoutException: write lock for /org/hibernate/cache/UpdateTimestampsCache/LOG_EVENT could not be acquired after 0 ms. Locks: Read lock owners: []
Write lock owner: Thread[http-8443-14,5,jboss]
(caller=GlobalTransaction:<16.173.241.57:9242>:119, lock info: <unlocked> (activeReaders=0, activeWriter=null, waitingReaders=0, waitingWriters=0, waitingUpgrader=0))
at org.jboss.cache.lock.IdentityLock.acquireWriteLock(IdentityLock.java:206)
at org.jboss.cache.Node.acquireWriteLock(Node.java:562)
at org.jboss.cache.Node.acquire(Node.java:509)
... 31 more
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-2305) refresh throws exception when database has been altered with a delete
by Markus Heiden (JIRA)
refresh throws exception when database has been altered with a delete
---------------------------------------------------------------------
Key: HHH-2305
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2305
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1, Oracle 9.2
Reporter: Markus Heiden
Attachments: hibernate.zip
First I save an entity with a collection of cascading entities in it and flush. Then I delete these cascaded entities with a sql query. When I now do a refresh on the entity an exception is thrown, because the cascaded entities couldn't be found in the database. I expected these entities to be deleted from the (in memory) collection of the entity instead.
Test case is attached. Stacktrace of test case:
Hibernate: select c0_.id as id2_0_, c0_.c as c2_0_ from C c0_ where c0_.id=?
org.hibernate.UnresolvableObjectException: No row with the given identifier exists: [hibernate.refresh.C#30003]
at org.hibernate.UnresolvableObjectException.throwIfNull(UnresolvableObjectException.java:42)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:126)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
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.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:911)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:894)
at org.hibernate.engine.CascadingAction$4.cascade(CascadingAction.java:169)
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.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:99)
at org.hibernate.event.def.DefaultRefreshEventListener.onRefresh(DefaultRefreshEventListener.java:39)
at org.hibernate.impl.SessionImpl.fireRefresh(SessionImpl.java:902)
at org.hibernate.impl.SessionImpl.refresh(SessionImpl.java:886)
at hibernate.refresh.Test.main(Test.java:46)
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3360) Custom Oracle Batcher to allow batch updates for versioned data
by Manuel Dominguez Sarmiento (JIRA)
Custom Oracle Batcher to allow batch updates for versioned data
---------------------------------------------------------------
Key: HHH-3360
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3360
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga
Environment: Oracle 10g R1, 10g R2, 11g R1 (have not tried previous Oracle versions), 11g R1 drivers (older drivers should also work)
Reporter: Manuel Dominguez Sarmiento
Priority: Minor
Attachments: C3P0OracleBatchingBatcher.java, C3P0OracleBatchingBatcherFactory.java, OracleBatchingBatcher.java, OracleBatchingBatcherFactory.java
We have developed a custom Oracle Batcher which allows batching versioned data. The Oracle JDBC driver does not return update counts when using the standard JDBC 2.0 batching mechanism, however the proprietary Oracle batching mechanism allows obtaining the total batch row update count. The update counts are absolutely necessary to detect stale updates.
Although it is not exactly the same, the total row update count is actually enough information to be able to batch versioned data and still detect stale updates.
We'd like to contribute the attached files. They have a compile time dependency on Oracle JDBC. If this is not acceptable, it could be easily solved by using reflection.
Another Batcher is provided for when the Oracle connection is being managed through c3p0 (a common deployment scenario). This has a compile time dependency on c3p0.
A few "dirty" tricks were necessary to pull this off without patching other classes. Specifically, it was necessary to override Java private semantics to obtain BasicExpectation.expectedRowCount. This could be easily solved by adding an accessor method to the Expectation interface.
There is one issue which we are not completely sure of, however so far we have not found any problems. When the Expectation is NONE, there is no way to check whether the total row count is correct or not, even if other batched updates do have expectations with expected row counts. Our understanding is that actually, since batching requires all statements to be of the same type (since the same PreparedStatement / CallableStatement is being used), then either ALL expectations will be NONE, or all will have an expected row count. We'd welcome comments from the Hibernate team. This could also be probably handled better by improving the Expectation interface.
Oracle JDBC docs that explain the Oracle batching model: http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraperf.htm#...
As expected, implementing this solution has resulted in drastical improvement in batch processing.
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3160) Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)
by Gail Badner (JIRA)
Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)
--------------------------------------------------------------------------------------------------
Key: HHH-3160
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3160
Project: Hibernate3
Issue Type: Sub-task
Reporter: Gail Badner
Assignee: Gail Badner
The logic used for removing entities from one-to-many list associations can cause ConstraintViolationException will be thrown if there are constraints on both (owner_id, position) and (child_id) in the "collection table". If the association is on a join table, the "collection table" is the join table; otherwise, the "collection table" is the child entity table..
Currently, SchemaExport does not put a constraint on (owner_id, position) when exporting one-to-many list associations on a foreign key. SchemaExport should be updated to also export this constraint.
See HHH-1268 for a description of how to reproduce this issue.
For one-to-many list associations on a foreign key, the workaround is to either define the constraint on (owner_id, position) in the child entity table as deferred. If this is not on option for a particular Dialect, the constraint on (owner_id, position) will have to be excluded.
For a one-to-many list association on a join table, the workaround is to either define the constraint on (child_id) in the join table as deferred. If this is not on option for a particular Dialect, the constraint on (child_id) will have to be excluded.
--
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
13 years, 1 month
[Hibernate-JIRA] Created: (HHH-3887) Envers hbm xml based configuration
by Helmut Pasch (JIRA)
Envers hbm xml based configuration
----------------------------------
Key: HHH-3887
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887
Project: Hibernate Core
Issue Type: Improvement
Components: envers
Affects Versions: 3.5
Environment: Hibernate: All Hibernate Versions including Envers as subproject
Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, ....
Reporter: Helmut Pasch
Currently the tool library Envers can only be configured / mapped to java POJOs by annotations. We would appreciate if this mapping could be done by hbm xml files. Using this approach the POJO won't be bound to Envers annotations. They simply would be left as POJOs instead of transformed to JPA like Entity Beans.
We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see only two options objects may leave the server tier. First by a copy to an annotation less value object, which is consuming performance and resources. Second by coping / using Envers / Hibernate libraries for reference purposes on the client tier.
Both solutions are not very attractive compared to the very well working hbm xml approach Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in client server communication model transformations like coping objects or transforming them to other formats like XML, e.g. like web services does. The easiest way would be to just serialize the Java POJO objects. But never then less the client should only depend (logically) on the server API. It is not intended to rely on a specific server implementation.
--
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
13 years, 1 month