]
Scott Van Wart updated HHH-2078:
--------------------------------
Attachment: locktest.zip
- Eclipse 3.3 project structure
- Expands to "locktest/"
- All JARs removed but listed in locktest/lib/list.txt
- Output of my last run is in locktest/output.lastrun.txt
- Semi-personal stuff replaced with (host)/(sid)/(user)/(password) in
locktest/src/hibernate.cfg.xml and locktest/output.lastrun.txt
Notice there's no "for update of..." in the second SQL output. If I leave
out 'lazy="false"' from the mapping file, there's only one fetch
(for the parent) even though LockMode.UPGRADE and cascade="lock".
for update on multiple tables does not work or is not present.
cascade='lock' does not always work as specified.
----------------------------------------------------------------------------------------------------------------
Key: HHH-2078
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2078
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.1.3
Environment: Oracle 9
Reporter: Peter Mutsaers
Attachments: locktest.zip
A normal one to many relationship between two classes, say A and B exists.
We have a cascade='lock' from A to B and also specified fetch='join'.
When I get only an instance of A, hibernate generates a left join between A and B.
When I get the instance while getting a lock, session.get(A.class, id,
LockMode.UPGRADE),
I would expect and need an SQL statement along the lines of "select .. from A a left
join B b on a.id=b.a_id FOR UPDATE", which would lock both A and its associated B
instances.
Instead, hibernate even refuses to execute the join in this case, and fetches A and B
with separate queries.
Also whatever I do, I cannot convince hibernate to generate a "for update"
query without specifiying a specific table.
For example when A and B have fetch="select" and B is lazily loaded, and I have
already retrieved an instance of A, then execute
session.lock(a, id, LockMode.UPGRADE), I would expect that the cascade='lock'
would also lock B by either generating the left join over A and B, or by executing both
"select ... from A for update" and "select ... from B for update".
Instead, only the first select statement is executed and B is NOT LOCKED at all in spite
of the cascade='lock' instruction.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: