4 Replies Latest reply on Jan 24, 2005 4:10 AM by belaban

    Problem with transaction isolation?

    abakaev

      In my first experiments with JBossCache I'm using it in standalone mode with the dummy Tx manager. The cache is populated with simple "ProductVO" objects having three primitive attributes (two numbers and a String).

      I'm having two threads starting one after another (I tried time intervals around 20-50ms) . The first one updates an entry in prepopulated cache. The update consists of calling cache get and then updating the object attributes; the change is intercepted by the cache and replicated. Both get and change are within a user transaction context like

      UserTransaction tx = new DummyUserTransaction(DummyTransactionManager.getInstance());
      tx.begin();
      try {
      ProductVO p = (ProductVO) cache.getObject(prodNode(prodId));
      p.setPrice(newPrice); //AOP interception
      tx.commit();
      } catch (Exception e) {
      tx.rollback();
      }


      The second thread reads the same record. The problem is that sometimes the "getter" thread returns the old value before the transaction commits, and sometimes the new one. The tran isolation level is read_committed (or higher, it does not matter).

      I tried both v. 1.2 and earlier versions with the same results..

        • 1. Re: Problem with transaction isolation?

          DummyTransactionManager included in the distro is only for testing only. It only supports single thread. If you want to test it out, you will need to plug in a different tm (e.g., running under JBoss AS).

          But if anyone volunteers to make the current DummyTransactionManager supporting concurrnecy, please jump in now. :-)

          -Ben

          • 2. Re: Problem with transaction isolation?
            twundke

            Ben,
            I was under the impression that the DummyTransactionManager supported multiple threads locally. It doesn't seem to support the transaction isolation levels on a cluster-wide basis (ie. all locking is local until commit() is called). My testing (which I admit hasn't been overly extensive) seemed to support this assertion. This is actually fine in my situation, but if it truly doesn't support multiple local threads then that's not so good.

            I'm stuck with using the cache in standalone mode (ie. no app server), so does anyone have any suggestions about other possible transaction managers? Otherwise I fear that I might be the one having to update the DummyTransactionManager! :-)

            Tim

            • 3. Re: Problem with transaction isolation?

              Tim,

              You are right. I had to retract my statement. It does support multiple threads locally since we do have a test case TxConcurrentBankUnitTestCase for this. :-)

              In terms of isolation level, there should be no difference though. I mean even if you are using AS tm, the locking behavior across cluster should be the same.

              Having said that, it is still recommended only for testing purpose though.

              -Ben

              • 4. Re: Problem with transaction isolation?
                belaban

                If you use isolation level of SERIALIZABLE, then the behvior you get is incorrect ! Reads and writes should have exclusive locks.
                Since we have tested that this works, please submit a short unit test that shows your issue.