[GLASSFISH-20011] [UB] joinedTx missed data from another instance Created: 23/Mar/13  Updated: 05/Jun/13

Status: Open
Project: glassfish
Component/s: docs
Affects Version/s: 4.0_b81
Fix Version/s: 4.0

Type: Bug Priority: Major
Reporter: sherryshen Assignee: Mike Fitch
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHL6.2 and JDK1.7.0_10


Tags: 4_0-release-notes, 4_0-release-notes-completed, 4_0-release-notes-drafted

 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.



 Comments   
Comment by sherryshen [ 23/Mar/13 ]

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.

Comment by Mitesh Meswani [ 26/Mar/13 ]

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

Comment by sherryshen [ 27/Mar/13 ]

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

Comment by sherryshen [ 18/Apr/13 ]

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

Comment by sherryshen [ 01/May/13 ]

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.

Comment by ethan.wang [ 09/May/13 ]

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.

Comment by Mike Fitch [ 16/May/13 ]

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.

Comment by Gail Risdal [ 31/May/13 ]

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.

Comment by Gail Risdal [ 05/Jun/13 ]

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.

Generated at Wed Jun 03 21:08:57 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.