Issue Details (XML | Word | Printable)

Key: GLASSFISH-20803
Type: Bug Bug
Status: Open Open
Priority: Major Major
Assignee: marina vatkina
Reporter: xj
Votes: 0
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
glassfish

Transaction is not committed when launching disable sub-command

Created: 09/Sep/13 02:26 AM   Updated: 09/Sep/13 02:26 AM
Component/s: ejb_container
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Environment:

Windows


Tags: licbug
Participants: marina vatkina and xj


 Description  « Hide

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.



There are no comments yet on this issue.