]
Scott Van Wart commented on HHH-2078:
-------------------------------------
I'm getting frustrated with this as well, and I can't find any further information
on it ANYWHERE. I have something like:
<class name="Parent">
<bag name="children" inverse="true"
cascade="lock">
<key column="parent_id" not-null="true"
on-delete="cascade" />
<one-to-many class="Child" />
</bag>
</class>
<class name="Child">
<many-to-one name="parent" column="parent_id"
not-null="true" />
</class>
Now I expect:
session.get( Parent.class, id, LockMode.UPGRADE );
To force a subsequent select of the child FOR UPDATE.
I even added "lazy=false" to the bag. It fetches with a subsequent select but
completely ignores the lock mode in the second select, making cascade="lock"
USELESS in this instance.
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
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: