[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2162) Optimisitic Locking unusable with 1..N of Set or List

[Olli Blackburn (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2162?page=comments#action_24922 ] 

Olli Blackburn commented on HHH-2162:
-------------------------------------

Christian, there seems to be some misunderstanding on all sides here. I raised this as a blocker after reading the definitions posted for your issue system at http://opensource.atlassian.com/projects/hibernate/ShowConstantsHelp.jspa?decorator=popup#PriorityLevels

  Blocker
      Blocks development and/or testing work, production could not run

As stated above, this problem means that any application using 1..N List or Set and detached objects (a common pattern, as you know) is in a "production could not run" state. Development is difficult and testing very challenging with constant OLEs being generated when they shouldn't be, even in single user testing.

  Minor
      Minor loss of function, or other problem where easy workaround is present.

This isn't a "minor loss of function". I don't need to tell you that optimistic locking is a major functional area and key to many scalable applications. I don't see an "easy workaround" - I'll gladly look at one if you can please point me towards it.


Would it be possible to please turn down the hostile tone around this issue? Everyone understands there's no money involved in our relationship, but that doesn't mean I'm not a "customer" of  "your product". With a paid-for product it benefits both sides to work together on issues (which is what I'm trying to do). IMO open source requires that even more so.

I raised what seems to be a significant issue for *Hibernate*. Yes it's significantly impacting my product, but I doubt I'm alone and don't understand your classification of it as "minor". Given the large gulf between blocker and minor, can you please give a few words of clarification as to why you consider it a minor to-do item, or what the workaround is? Through open dialog I'm sure we can all see each other's point of view.  Thanks. 

> Optimisitic Locking unusable with 1..N of Set or List
> -----------------------------------------------------
>
>          Key: HHH-2162
>          URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2162
>      Project: Hibernate3
>         Type: Patch

>   Components: core
>     Versions: 3.2.0.ga
>  Environment: Core 3.2 GA
> EM 3.2 GA
> HSQLDB 1.8.0.2 in memory
>     Reporter: Olli Blackburn
>     Priority: Minor
>  Attachments: CollectionType.patch, Playpen.zip
>
>
> Calling merge() on an unmodified entity with 1..N relationship using Set or List results in the entity being marked dirty, its version number is increased and an SQL UPDATE performed on it. This makes it impossible to achieve any kind of sensible concurrency in our application which makes extensive use of detached objects.
> See the attached test case (packaged as a complete eclipse 3.2 project). Set EJB3_HOME, HIBERNATE_HOME and HSQLDB_HOME in your eclipse workspace preferences and then run the included PojoTest launcher to see it run.
> The test populates the DB, does a select by name, merge, merge and select by name again. Each of these five steps is in its own Tx and entity manager. The test is repeated for Set, Map and List. Interesting Map seems to work, but as our application doesn't use Maps that's little comfort to us. The pojo is not being modified (by my code) between the merge calls(), yet I get the following output (each print is before the commit following the operation): 
> findByUniqueName: PojoHashSet4 version=2
> merge: PojoHashSet4 version=2
> merge: PojoHashSet4 version=3
> findByUniqueName: PojoHashSet4 version=5
> findByUniqueName: PojoHashMap4 version=0
> merge: PojoHashMap4 version=0
> merge: PojoHashMap4 version=0
> findByUniqueName: PojoHashMap4 version=0
> findByUniqueName: PojoArrayList4 version=0
> merge: PojoArrayList4 version=0
> merge: PojoArrayList4 version=1
> findByUniqueName: PojoArrayList4 version=2
> HHH-1401 and HHH-1668 seem like they might be related to my problem, but debugging my test case shows otherwise. The problem seems to be caused by the replacement of the empty collection with a new empty collection. More specifically, the empty target collection is cleared, marking it dirty, even though it contains no members is is about to have nothing copied in it. This occurs in org.hibernate.type.CollectionType.replaceElements(). 
> Looking at the code paths I think the problem runs deeper than my empty collection case. If the source and target being copied by replaceElements() are identical (whether zero length or not), the target will be marked dirty  due to the result.clear() call in replaceElements(). It seems there needs to be a pre-check for this case to avoid the whole clear and copy process with it's associated setting of "dirtiness".
> I'm attaching a patch for CollectionType which fixes the problem in the testing we've performed. 
> Feedback and comments appreciated.

-- 
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