glassfish
  1. glassfish
  2. GLASSFISH-20011

[UB] joinedTx missed data from another instance

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.0_b81
    • Fix Version/s: 4.0
    • Component/s: docs
    • Labels:
      None
    • Environment:

      RHL6.2 and JDK1.7.0_10

      Description

      joinedTx missed data from another instance

      glassfish-4.0-b82-03_23_2013.zip

      With the fix for
      http://java.net/jira/browse/GLASSFISH-19597
      appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb
      tests passed on das, or using one cluster instance,
      but got 1 failure on using 2 cluster instances of cluster.
      I will provide test details next.

        Activity

        Hide
        sherryshen added a comment -

        To use sqe-cluster env, please refer II B.
        http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/4.0+Core+Test+Instructions

        In sqe-cluster env, to reproduce the problem in test dir
        appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb
        do "ant ee all_run2" and see failure with using 2 instances.
        test1: passed
        persist data1, not joinedTx, em.flush from instance1
        verify db without data1

        test2: passed
        persist data2, joinedTx from instance2
        verify db with data2

        test3: failed.
        persist data3, not joinedTx, from instance1
        verify db without data3, passed.
        verify db with data1, failed.

        As a comparison,
        do "all ee all_run1" and see tests all passed with using 1 instance.

        Show
        sherryshen added a comment - To use sqe-cluster env, please refer II B. http://aseng-wiki.us.oracle.com/asengwiki/display/ASQA/4.0+Core+Test+Instructions In sqe-cluster env, to reproduce the problem in test dir appserver-sqe/pe/ejb/jpa20/war/unsyncpcsfsb do "ant ee all_run2" and see failure with using 2 instances. test1: passed persist data1, not joinedTx, em.flush from instance1 verify db without data1 test2: passed persist data2, joinedTx from instance2 verify db with data2 test3: failed. persist data3, not joinedTx, from instance1 verify db without data3, passed. verify db with data1, failed. As a comparison, do "all ee all_run1" and see tests all passed with using 1 instance.
        Hide
        Mitesh Meswani added a comment -

        As this is related to clustering, deferring this for 4.0.1. Ethan and Quiang will investigate further.

        Show
        Mitesh Meswani added a comment - As this is related to clustering, deferring this for 4.0.1. Ethan and Quiang will investigate further.
        Hide
        sherryshen added a comment -

        I enabled HA to see if it helps for 20011, but it failed
        with a different error, see details in
        http://java.net/jira/browse/GLASSFISH-20081

        Show
        sherryshen added a comment - I enabled HA to see if it helps for 20011, but it failed with a different error, see details in http://java.net/jira/browse/GLASSFISH-20081
        Hide
        sherryshen added a comment -

        Qiang has a very good description about tests. I am exploring how unsyncPC can
        work in cluster env. Especially, how to make joinTx in test2 (instance2) to take care the data in test1 (instance1)?

        On 4/17/2013 7:39 PM, Qiang Liu wrote:
        > Hi Mitesh
        > Ethan and I have discussed this test cases together before, and I can give a brief description for it:
        >
        > 1. The first request is sent to Instance 1, the EJB tries to persist Employee 1 and Employee 2 with not joining transaction, and then flush PC. An expected exception is caught.
        >
        > 2. The second request is sent to Instance 2, the EJB tries to persist Employee 3 and Emploee4 after join transaction. Even the flush is not invoked, the entities will be persisted to DB when the transaction is committed. But, since this is difference instance from Step 1, Employee 1 and Employee 2 will not be persisted to DB in this step.
        >
        > 3. The third request is sent to Instance 1, the EBJ tries to persist Employee 5 and Employee 6 without joining transaction, as it doesn't invoke the flush method, all the entities will not be persisted to DB. But, here the test case expects Employee 1 involved in PC in Step 1 will be persisted to DB in Step 2. Since the EM and PC will not be synced between instances in cluster env, so the test3 will not pass.
        >
        > Thanks
        > -Qiang

        Show
        sherryshen added a comment - Qiang has a very good description about tests. I am exploring how unsyncPC can work in cluster env. Especially, how to make joinTx in test2 (instance2) to take care the data in test1 (instance1)? On 4/17/2013 7:39 PM, Qiang Liu wrote: > Hi Mitesh > Ethan and I have discussed this test cases together before, and I can give a brief description for it: > > 1. The first request is sent to Instance 1, the EJB tries to persist Employee 1 and Employee 2 with not joining transaction, and then flush PC. An expected exception is caught. > > 2. The second request is sent to Instance 2, the EJB tries to persist Employee 3 and Emploee4 after join transaction. Even the flush is not invoked, the entities will be persisted to DB when the transaction is committed. But, since this is difference instance from Step 1, Employee 1 and Employee 2 will not be persisted to DB in this step. > > 3. The third request is sent to Instance 1, the EBJ tries to persist Employee 5 and Employee 6 without joining transaction, as it doesn't invoke the flush method, all the entities will not be persisted to DB. But, here the test case expects Employee 1 involved in PC in Step 1 will be persisted to DB in Step 2. Since the EM and PC will not be synced between instances in cluster env, so the test3 will not pass. > > Thanks > -Qiang
        Hide
        sherryshen added a comment -

        Mitesh, Ethan and I discussed this issue on April 29, 2013. We agreed
        that the failure is due to the limitation of JPA2.1 feature,
        unsynchronized persistence context.
        It can be documented for 4.0 release, and addressed for later release.
        Transfer the bug to docs.

        Show
        sherryshen added a comment - Mitesh, Ethan and I discussed this issue on April 29, 2013. We agreed that the failure is due to the limitation of JPA2.1 feature, unsynchronized persistence context. It can be documented for 4.0 release, and addressed for later release. Transfer the bug to docs.
        Hide
        ethan.wang added a comment -

        After discussions with Mitesh and Sherry, we all agreed on following content to document:

        Any updates to unsynchronized persistence context, while it's not joint to the current transaction is neither persisted to database nor replicated in cluster therefore subject to data loss. Developers should understand that before joining the PC with current transaction and the transaction being committed, all updates to the PC are only visible to the server instance which it resides and would not survive from server crash or fail over, so cautions should be exercised using unsynchronized PC in data critical application.

        Show
        ethan.wang added a comment - After discussions with Mitesh and Sherry, we all agreed on following content to document: Any updates to unsynchronized persistence context, while it's not joint to the current transaction is neither persisted to database nor replicated in cluster therefore subject to data loss. Developers should understand that before joining the PC with current transaction and the transaction being committed, all updates to the PC are only visible to the server instance which it resides and would not survive from server crash or fail over, so cautions should be exercised using unsynchronized PC in data critical application.
        Hide
        Mike Fitch added a comment -

        Added 4_0-release-notes tag so this gets documented in the 4.0 release notes. Leaving the issue Open so the information can get integrated into the appropriate manual for the next release.

        Show
        Mike Fitch added a comment - Added 4_0-release-notes tag so this gets documented in the 4.0 release notes. Leaving the issue Open so the information can get integrated into the appropriate manual for the next release.
        Hide
        Gail Risdal added a comment -

        Added the following to the release notes:

        [UB] joinedTx missed data from another instance (20011)

        Description
        Updates made to an unsynchronized persistence context before it is joined to the current transaction and the transaction is committed are not persisted to a database or replicated in a cluster and data could be lost in the event of a server crash or failover.

        Workaround
        None. This is a limitation of the JPA 2.1 feature. Exercise caution when using an unsynchronized persistence context in a data-critical application.

        Show
        Gail Risdal added a comment - Added the following to the release notes: [UB] joinedTx missed data from another instance (20011) Description Updates made to an unsynchronized persistence context before it is joined to the current transaction and the transaction is committed are not persisted to a database or replicated in a cluster and data could be lost in the event of a server crash or failover. Workaround None. This is a limitation of the JPA 2.1 feature. Exercise caution when using an unsynchronized persistence context in a data-critical application.
        Hide
        Gail Risdal added a comment -

        Revised release notes write-up slightly to now read:

        Description
        Updates made to an unsynchronized persistence context before it is joined to the current transaction and the transaction is committed are not persisted to a database or replicated in a cluster and data could be lost in the event of a server crash or failover.

        Workaround
        None. This is working as designed. The JPA 2.1 feature delays synchronization to a database until explicitly instructed to synchronize. Exercise caution when using an unsynchronized persistence context in a data-critical application.

        Show
        Gail Risdal added a comment - Revised release notes write-up slightly to now read: Description Updates made to an unsynchronized persistence context before it is joined to the current transaction and the transaction is committed are not persisted to a database or replicated in a cluster and data could be lost in the event of a server crash or failover. Workaround None. This is working as designed. The JPA 2.1 feature delays synchronization to a database until explicitly instructed to synchronize. Exercise caution when using an unsynchronized persistence context in a data-critical application.

          People

          • Assignee:
            Mike Fitch
            Reporter:
            sherryshen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: