7 Replies Latest reply on Aug 1, 2003 3:16 PM by Grzegorz Stelmaszek

    Read-Only methods and repeatable reads

    lfinis Newbie

      I'm using commit option A because i need cache.
      Pretty soon it became obvious that i have to mark many getters as "read-only" since too many transactions were rolled back because of the deadlocks.

      My question is: Is it true that commit option A + pessimistic lock + read only methods, is equivalent of READ_COMMITED isolation level?

      Example:
      1)TX1(Session bean) reads "read-only" property on entity bean A without acquiring the lock
      2)TX2 modifies entity bean A (acquires lock and commits).
      3)TX1 has stale data (not repeatable read) and uses this data to update entity bean B.

      Result of all this is inconsistency between bean A and B
      Does the use of "read-only" methods mean compromising on isolation level (consistency).

      Thanks in advance.

        • 1. Re: Read-Only methods and repeatable reads
          Grzegorz Stelmaszek Newbie

          Hi,

          I'm trying to achieve read_commited isolation level, and I think your conclusion is not quite right.

          Calling a read-only method acquires a lock for the time of 'running' this method. This lock is releasted immediately after returning from it, but if something else holds the lock when calling a read-only method, it must wait.

          The consequence thus is severe, as there are deadlocks possible even though no set() methods are called (actually this is the case we hit), which on isolation level read_commited is not possible at all.

          best regards,
          greg

          • 2. Re: Read-Only methods and repeatable reads
            Marc Sturm Newbie

            Greg,

            Thanks for your answer, I am still running into too many deadlocks with these read-only methods. Is there a way to set up jboss so calling a read-only method does not acquire a lock?
            Thanks again.

            Marc

            • 3. Re: Read-Only methods and repeatable reads
              Grzegorz Stelmaszek Newbie

              hi,

              I think it's hardly possible :(. Anyway I'm working on it, so if I find out the answer I'll let you know.

              In the meantime we switched to a different container-configuration, namely "Instance per transaction" for entities. This eliminated all our deadlocks for the cost of performance (3 times slower as caching is not possible).

              best regards,
              greg

              • 4. Re: Read-Only methods and repeatable reads
                Marc Sturm Newbie

                Thanks
                I am just trying also the "Instance per transaction" and it is indeed slower but as you say with no deadlocks. Not good enough for me, so I was thinking of creating a read-only bean that points to the same table and that will be called only for reading. Do you think it is feasable? I will try and let you know.

                Marc

                • 5. Re: Read-Only methods and repeatable reads
                  nraghuram Newbie

                  Hi,
                  the documentation says that read only beans and read only methods do not acquire a transaction lock. Am i misinterpreting it, because as per your posts, the bean is getting locked on read too.
                  regards
                  raghu

                  • 6. Re: Read-Only methods and repeatable reads
                    Marc Sturm Newbie

                    hi raghu,

                    I think you are reading it correctly, I looked closely to the deadlocks generated in my app and realised there were generated by other beans that did not have any read-only method though used for read-only. I corrected it and the deadlocks disapeared.... So I am not doing what I posted above and I believe you and the documents are correct.

                    Marc

                    • 7. Re: Read-Only methods and repeatable reads
                      Grzegorz Stelmaszek Newbie

                      Hi,

                      Weird indeed, weird I must say. I set 'method-attributes read-only=true for pattern get* . I assume that all getters now should not acquire tx locks permanently.

                      So is it at all possible for deadlock to occur if we are using only such read-only getters? Cause we are getting deadlocks still, but now when accessing CMR fields :(. Why? why? why? I have compelling feeling that this lock code is a little bit broken...

                      greg