[GLASSFISH-20803] Transaction is not committed when launching disable sub-command Created: 09/Sep/13  Updated: 09/Sep/13

Status: Open
Project: glassfish
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: xj Assignee: marina vatkina
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Tags: licbug

 Description   

Symptom:

With EJB's CMT(Container-Managed Transactions) in Java EE 7 RI, the
following exception is thrown if "asadmin disable" command is launched
when business method is till in execution.

javax.ejb.EJBException: Attempt to invoke when container is in STOPPED

However, rollback never be executed.

It seems a bug exists in the code at com.sun.ejb.containers.BaseContainer.java#postInvoke(EjbInvocation, boolean).

REPRODUCE:

The attached test case is for OracleDB.

1) Run the attached createTable_Oracle.sql and create testtable in DB
2) Run start-domain.bat and start the domain(default domain1)
3) Run the attached create-jdbc.bat and create JDBC resources
4) Run the attached deploy.bat and deploy applications
5) Click URL.url to open a browser and show adder.html
6) Input some value in the text box and click "Send query" button

This step does:

  • Accesses to EJB from servlet
  • Update testtable (update the value of balance with id:001 )
  • Sleep 10 seconds

7) When the above step 6) is running, invoke disable.bat to stop the application

Here, javax.ejb.EJBException is thrown and the message
500 Internal Server Error
shows up.

Then, confirm the contents of testtabel in DB.
The value should be the previous value (the value before update)

8) Run the attached stop-domain.bat to stop the domain

Then, confirm the contents of testtabel in DB.
The value is updated.(value after update)

At step 7), if rollback is executed and the value in DB is the previous value,
this is what expected behavior.
However, transaction is committed at step 8) which should have happened at step 7). As a result, the value is updated incorrectly.


Generated at Sat Apr 30 23:32:19 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.