4 Replies Latest reply on Aug 6, 2009 3:07 PM by lvdberg

    Conversation + Concurrent Entity modifications

    kloss

      Hi, i need to understand a conversation and transaction isolation strategy. I work´s in conversation context propagated for various views, but this is initialized in view of list of objects.
      Ok, i use @DataModel and @DataModelSelection for redirect a edit,delegate, cancel or aceppt views, and works ok. My use-case is a basically workflow, where a pre-requisite for user is a concurrent modification, for example:
      if user1 modify a entity id 1 in browser 1 and user2, 3 etc.. logged in workflow in other browser the modifications have been updated for all. But, the conversation
      not update data of list with database while conversation is not ended. Any suggestion for this ?


      Regards
      Kloss

        • 1. Re: Conversation + Concurrent Entity modifications
          asookazian

          From 9.3.3 of Seam ref doc:



          As with any optimistic transaction management, transaction isolation and consistency can be
          achieved via use of optimistic locking. Fortunately, both Hibernate and EJB 3.0 make it very easy
          to use optimistic locking, by providing the @Version annotation.

          You also need to find out what the transaction isolation level is for your db vendor.  MySQL, for example, defaults to repeatable read whereas MSSQL is read committed.  If that is not sufficient, you can override the default setting in *-ds.xml file using <transaction-isolation>.



          But, the conversation not update data of list with database while conversation is not ended. Any suggestion for this ?

          Not sure I quite understand.  What is the problem and/or post stack trace with your EntityManager API code.

          • 2. Re: Conversation + Concurrent Entity modifications
            lvdberg

            Hi Rafael,


            If I understand it well you want to have different users working on the same entity (updating). Each user receives its own copy of the entity in his session while editing it. If - before saving - another user edits it, you normally would overwrite that entity, you implemnt optimistic locking in your application. A simple addition of a version column (a property with a @Version annotation) helps Hibernate detecting conflicts.


            Adding a version is the first part of the trick. The other one is that you must catch the resulting error with Seam (and do whatever is neccessary). This is done by adding the following in your pages.xml


                 


            <exception class="javax.persistence.OptimisticLockException">
                 <end-conversation before-redirect="true" />
                 <redirect view-id="GoToThePageYouWantToGo.xhtml">
                      <message>
                           Different users tried to update the same Incident
                      </message>
                 </redirect>
            </exception>




            Hopefully this helps,


            Leo

            • 3. Re: Conversation + Concurrent Entity modifications
              kloss

              Tank´s for reply, the post of Leo could be a part of my solution, but the user need a concurrent modification. My scenario have a root conversation and more nested conversations. I discovered that my problem is resolved with a simple refresh() on objects cached in entityManager first level cache of hibernate or clear(), because the unique entityManager is opened in time of conversation. Now, have a other problem, the hibernate not respect the CacheMode for org.hibernate.CacheMode.REFRESH, that theoretically is also avaliable for this. Would any interference of seam ?


              Best Regards
              Kloss

              • 4. Re: Conversation + Concurrent Entity modifications
                lvdberg

                Rafael,


                Use the event mechanism to trigger refresh. In my application the refresh of a list of objects is controlled by an ajax-pull, whenever an ntity changes (or a new entity is added) the an event is raised and passed to the an eventListener of the ajax-pull. It is a bit complex because you can't send events from one session to another. You need an application scoped nbean to do that.


                I use the excepion handlers, because every users can be changing entities in his/her own session, and whenever something has changed an OptimisticLocking exception will occur, I my case leading to a warning that the system was unable to perform the update.