[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2078) for update on multiple tables does not work or is not present. cascade='lock' does not always work as specified.

[Gail Badner (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_28468 ] 

Gail Badner commented on HHH-2078:
----------------------------------

Please attach a runnable test case (Java + mapping) that reproduces the issue. If it is not possible to make it fail, it will still help for investigating this issue.

> 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: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira