5 Replies Latest reply on Jul 16, 2009 2:22 AM by mickclarke138

    Long running Seam managed transaction

    waquin
    waquin Jul 15, 2009 2:08 AM

      Hello,


      I am investigating using Seam managed transactions across multiple requests within a long running conversation.
      What I want to achieve is the following situation:




      1. Conversation and transaction started. (Via Seam managed transaction)

      2. User selects and pessimistically locks an entity.

      3. Entity returned to the front end for editing.

      4. User finishes editing.

      5. Entity is updated and lock released.

      6. Transaction committed and conversation ended. (Via Seam managed transaction)



      My current issue is extending, or storing, the transaction so that the lock is retained with the conversation right until the commit. I understand that one transaction is used during the request phase and one is used during the response.


      Does anyone have an solutions, hints as to which path to follow, or is this not currently possible(and why)?

        • 1. Re: Long running Seam managed transaction
          swd847
          swd847 Jul 15, 2009 2:19 AM (in response to waquin)

          Don't do this. It is very bad.


          It kills scalability and greatly increases the chance of database deadlocks and other database issues.


          If you absolutely must have pessimistic locking then I would roll my own using jboss cache (or some other store of your choice). When the user selects an entity create a cache node in a specifc place (e.g. /locks/myEntity/id), you also have to make sure that the cache is configured properly so that two users cannot create the node at once. If the cache node exists then the entity is locked and no one else can edit it.


          Stuart

            • Actions
          • 2. Re: Long running Seam managed transaction
            waquin
            waquin Jul 15, 2009 3:39 AM (in response to waquin)

            Thanks for the reply.


            Two things



            • We are pointing to a database that is accessed by external parties so true database pessimistic locking is a requirement.

            • The application has a small user base (less than 100 concurrent users) and scalability is not an issue. We are using seam/ejb for the security benefits.



            With this in mind, what options do we have?

              • Actions
            • 3. Re: Long running Seam managed transaction
              swd847
              swd847 Jul 15, 2009 5:57 AM (in response to waquin)

              Your going to have to roll it yourself, seam transaction management was not designed for this situation (with good reason).



              Good luck, I think your going to need it.


              Stuart

                • Actions
              • 4. Re: Long running Seam managed transaction
                jeanluc
                jeanluc Jul 15, 2009 7:18 AM (in response to waquin)

                The application has a small user base (less than 100 concurrent users) and scalability is not an issue.

                Scalability (or the lack thereof) may not be an issue for you, but performance will be even for those 100 users.


                Try to decouple the locking from the db transactions. Also, do you need the locking both ways (when your app edits the data and when the external parties edit the data) or only in one of those cases?

                  • Actions
                • 5. Re: Long running Seam managed transaction
                  mickclarke138
                  mickclarke138 Jul 16, 2009 2:22 AM (in response to waquin)

                  Scalability (or the lack thereof) may not be an issue for you, but performance will be even for those 100 users.

                  There is no correlation between pessimistic locking and performance. This is a widely held myth that is worryingly gaining respect. This is underlined with the EJB3 and JPA specs not supporting it. An alarming tread that is dumbing down Java. It is misuse that leads to issues of performance, deadlocks and alike, not any locking strategy. If the locking strategy were a culprit the big RDBMS vendors would not support it. They do and in a highly tunable manner.


                  The OP has a need to use pessimistic locking. It appears that Seam does not support it due to the underlying specifications.

                    • Actions