Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: v3.0.1
    • Fix Version/s: 3.1_dev
    • Component/s: jca
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: Macintosh

    • Issuezilla Id:
      12,383

      Description

      Using Hibernate, though I suspect this happens with other implementations as well, when some updates/ inserts are
      flushed in a ejb method, and other updates/inserts are flushed at commit, an error will sometimes occur.
      The error happens when the same data is updated both before and after the flush in the ejb method.
      The issue appears to be that the same database connection is not reused when the session is flushed at commit. This
      causes the update to fail because the updates from the first connection are not committed yet, and therefor are not visible
      to the second connection.
      Worse still is that when the rollback statement is issue, it is only issue on the first connection, not the second connection
      leaving the database in a inconstant state with some updates/ inserts being left.

      I have been able to reproduce this behaviour reliably and can confirm that more then one connection is being used by
      tracing the connections and queries via the database directly.

      to replicate this:
      1) Call and ejb session bean method with cmt
      2) retrieve some hibernate objects, and modify one
      3) call any hql finder method or call session.flush()
      4) Modify the same object again as in step 2

      When the method completes the jta transaction manager will call hibernate to flush the session at which point you will get
      a StaleObjectStateException because the version number of the modify entity will not match.

      I have also run the same code on Glassfish 2.1.1 and WebSphere 5.1 (where we are migrating from) and it executes as
      expected with only one connection being used.

      To avoid duplicating the same infor again, see post:
      http://forums.java.net/jive/thread.jspa?threadID=151083&tstart=0

      This is a show stopper issue for us as we using this pattern through out. For the time being we are going to target v2.1.1
      instead.

      Please contact me if you require any further details.

      1. address_sql.txt
        1 kB
        nztraveller
      2. domain.xml
        14 kB
        nztraveller
      3. it-12383.tar.gz
        7 kB
        Jagadish
      4. Re- [Issue 12383] [jca] new db connection is used on commit
        11 kB
        nztraveller
      5. server.log
        9 kB
        Shalini
      6. sql_trace.txt
        4 kB
        nztraveller
      7. stack_trace.txt
        30 kB
        nztraveller

        Activity

        Hide
        nztraveller added a comment -

        Hi.
        The important detail is using the table type INNODB. It needs to be a transactional database.
        I had several emails back and forth with sm157516 and he was able to reproduce the issue as well.
        Believe me it is a bug. We have just completed our migration to glassfish, and end using v2, we would have
        much rather been on v3. And now once this has been resolved I have the work of moving from v2 to v3.
        I have attached the email trail.

        Cheers,
        Jason

        Show
        nztraveller added a comment - Hi. The important detail is using the table type INNODB. It needs to be a transactional database. I had several emails back and forth with sm157516 and he was able to reproduce the issue as well. Believe me it is a bug. We have just completed our migration to glassfish, and end using v2, we would have much rather been on v3. And now once this has been resolved I have the work of moving from v2 to v3. I have attached the email trail. Cheers, Jason
        Hide
        nztraveller added a comment -

        Created an attachment (id=5267)
        emails with Shalini Muthukrishnan

        Show
        nztraveller added a comment - Created an attachment (id=5267) emails with Shalini Muthukrishnan
        Hide
        Jagadish added a comment -

        Thanks, InnoDB engine does the trick.
        I am able to reproduce it intermittently.

        • Not sure why InnoDB alone is causing the issue and not the other engines
          (default one)
        • But, it seems to work fine in GlassFish 2.x and not in v3.x ?

        I shall investigate further.

        Show
        Jagadish added a comment - Thanks, InnoDB engine does the trick. I am able to reproduce it intermittently. Not sure why InnoDB alone is causing the issue and not the other engines (default one) But, it seems to work fine in GlassFish 2.x and not in v3.x ? I shall investigate further.
        Hide
        Jagadish added a comment -

        Fix will be available from GF 3.1 promoted build 29 or 11th Nov 2010 nightly.

        Show
        Jagadish added a comment - Fix will be available from GF 3.1 promoted build 29 or 11th Nov 2010 nightly.
        Hide
        tosehee added a comment -

        What was done to resolve this?

        I am using latest 3.1.1 release, and I still have this exact issue..

        Show
        tosehee added a comment - What was done to resolve this? I am using latest 3.1.1 release, and I still have this exact issue..

          People

          • Assignee:
            Shalini
            Reporter:
            nztraveller
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: