Cannot make use of concurrency-strategy (more readable)

Question

          Hi!
          First goes the abstract: despite all other parameters, the only setting that seems
          to make a difference for transaction handling is <isolation-level>. What I really
          want to make use of, is <concurrency-strategy>. Ultimately I want to make use of
          Optimistic concurrency strategy of WL70, but looks like that even Exclusive strategy
          does not work in my case.
          Here is my description of my test app:
          1. I have TxDataSource defined in Weblogic Console. Standard Datasource seems not
          to support transactions at all.
          2. I have two instances of the Client -- C1 and C2, Session Bean -- S, and Entity
          Bean -- E.
          3. I start C1, it locates S and calls business method with Required attribute on
          it.
          4. Business method on S finds E using E.find(PK). All methods on E has attribute
          Mandatory.
          5. Business method on S goes to sleep for 15 seconds: Thread.sleep(15000). I know
          that in real-world applications one cannot use threads in EJB, but I have to test
          concurrent access to the same data from different clients and this was the easiest
          way to do what I needed. Anyway, it is just a test.
          6. While S is sleeping in business method, I start C2. It locates S (creates new
          instance?), calls business method on it, which in turn, locates E (new instance of
          E?), calls find() on it and goes to sleep for the same 15 seconds. Note, that for
          <concurrency-strategy>Exclusive</concurrency-strategy> I expected second client to
          be unable to find() Entity bean, because it should be locked by the first client.
          Quite opposite, it can be located by S. This is weird for me.
          7. Business method on S for the first client awakes and calls business method on
          E (with Mandatory attribute). It changes data and commits. Fine.
          8. Business method on S for the second client awakes and calls business method on
          E to change data. Then it exits, and - surprise! - commits data! Even in Exclusive
          mode. The same thing in Optimistic mode with <verify-columns> parameter.
          <isolation-level> set to TRANSACTION_READ_COMMITTED, server is Sybase Adaptive Server
          v.12.
          The record in database is not locked on find(), because I can UPDATE record using
          Sybase SQL Advantage client.
          If I change <isolation-level> to TRANSACTION_REPEATABLE_READ or TRANSACTION_SERIALIZABLE,
          then record is locked at find(). But this does not have anyhting with optimistic
          locking! I want record to remain unlocked and to be checked for possible update by
          other client during commit! Also, for Exclusive mode I suppose that I cannot even
          find() entity bean for the same PK, that was already found by other client. What
          am I doing wrong?
          Additional info is attached.
          [qqq.txt]
          

Answer 1

Hi Mike,
          as I already posted I resolved the problem. Thanks anyway. My biggest
          mistake was that I was evaluating WL7 features, and to make my like easier,
          I was changing settings in the deployment descriptors within JAR file! Heh,
          because I did not run EJBC, I had stale classes in JAR file (those stubs and
          other helper classes that WL generates), that is why the whole thing did not
          work. Those stubs are generated by WLS based on setting in descriptors, that
          I personally find wrong, because it turns the whole "write code -- change
          descriptor while deploing" idea upside down. Anyway, t was my mistake.
          It works now with "Read" and "Modified" concurrency methods, but does not
          work with Timestamp field. Frankly, I did not try hard to make it work with
          Timestamp.
          So, when I understood the fact that <concurrency-strategy> works on bean
          level, and <isolation-level> works on database level, everything became
          clear.
          WBR,
          Michael Jouravlev.
          "mike" <[email protected]> wrote in message
          news:[email protected]...
          >
          > Hi.
          > I'm just done struggling with similar case. Difference is I use Oracle
          (have not
          > used SB for a while...) and 6.1. Both minor, IMHO. Also please
          <imho></imho> each
          > statement below.
          >
          > "Michael Jouravlev" <[email protected]> wrote:
          > >
          > >
          > >
          > >Hi!
          > >
          > >First goes the abstract: despite all other parameters, the only setting
          > >that seems
          > >to make a difference for transaction handling is <isolation-level>. What
          > >I really
          > >want to make use of, is <concurrency-strategy>. Ultimately I want to make
          > >use of
          > >Optimistic concurrency strategy of WL70, but looks like that even
          Exclusive
          > >strategy
          > >does not work in my case.
          >
          > Strategy must be supported by underlying DB and communicated to it via
          driver. If
          > it's either not supported, or driver can't tell DB what you want...
          >
          > >
          > >Here is my description of my test app:
          > >1. I have TxDataSource defined in Weblogic Console. Standard Datasource
          > >seems not
          > >to support transactions at all.
          >
          > That's for sure.
          >
          > >2. I have two instances of the Client -- C1 and C2, Session Bean -- S,
          and
          > >Entity
          > >Bean -- E.
          > >3. I start C1, it locates S and calls business method with Required
          attribute
          > >on
          > >it.
          > >4. Business method on S finds E using E.find(PK). All methods on E has
          attribute
          > >Mandatory.
          > >5. Business method on S goes to sleep for 15 seconds:
          Thread.sleep(15000).
          > >I know
          > >that in real-world applications one cannot use threads in EJB, but I have
          > >to test
          > >concurrent access to the same data from different clients and this was
          the
          > >easiest
          > >way to do what I needed. Anyway, it is just a test.
          > >6. While S is sleeping in business method, I start C2. It locates S
          (creates
          > >new
          > >instance?), calls business method on it, which in turn, locates E (new
          instance
          > >of
          > >E?), calls find() on it and goes to sleep for the same 15 seconds. Note,
          > >that for
          > ><concurrency-strategy>Exclusive</concurrency-strategy> I expected second
          > >client to
          > >be unable to find() Entity bean, because it should be locked by the first
          > >client.
          > >Quite opposite, it can be located by S. This is weird for me.
          >
          > It is not. It looks like you do have optimistic locking (Oracle uses it by
          default,
          > I do not know about Sybase). In such case any number of clients can try
          to modify
          > the data, they'll be happy ... till they try to commit.
          >
          > >7. Business method on S for the first client awakes and calls business
          method
          > >on
          > >E (with Mandatory attribute). It changes data and commits. Fine.
          > >8. Business method on S for the second client awakes and calls business
          > >method on
          > >E to change data. Then it exits, and - surprise! - commits data! Even in
          >
          > Yes, that sounds wrong at first. Though ... See: you can log into a DB and
          execute
          > update without prior locking. That is what happens. You edit stale data.
          >
          > To avoid this people use "version numbers", or whatever you want to call
          it. This
          > is a number, which has to be changed with each update and verified against
          while
          > modifying data in DB.
          >
          > >Exclusive
          > >mode. The same thing in Optimistic mode with <verify-columns> parameter.
          > >
          > ><isolation-level> set to TRANSACTION_READ_COMMITTED, server is Sybase
          Adaptive
          > >Server
          > >v.12.
          > >
          > >The record in database is not locked on find(), because I can UPDATE
          record
          > >using
          > >Sybase SQL Advantage client.
          > >
          > >If I change <isolation-level> to TRANSACTION_REPEATABLE_READ or
          TRANSACTION_SERIALIZABLE,
          > >then record is locked at find(). But this does not have anyhting with
          optimistic
          > >locking! I want record to remain unlocked and to be checked for possible
          >
          > That does. By changing locking scheme you switch from optimistic to
          pessimistic locking.
          >
          > >update by
          > >other client during commit! Also, for Exclusive mode I suppose that I
          cannot
          > >even
          > >find() entity bean for the same PK, that was already found by other
          client.
          > >What
          > >am I doing wrong?
          > >
          > >Additional info is attached.
          >