[
https://issues.apache.org/jira/browse/DERBY-5910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13479079#comment-13479079
]
Rick Hillegas commented on DERBY-5910:
--------------------------------------
Thanks for the third rev of the patch, Kim.
> Just a sanity check...
At the end of the try-with-resources block, the JRE calls the close() method on
the Derby connection.
If Derby encounters an error while processing a statement, Derby does the
following:
1) If the error is statement-severity, then Derby releases resources held by
the statement. But there may still be in-flight transactional work left over
from previous statements in the transaction. If so, then Derby will raise an
exception when the JRE calls Connection.close() on exiting the
try-with-resources block. This is the problem case.
2) If the error is transaction-severity, then Derby does (1) and rolls back the
transaction. The connection is now clean so Derby will not raise an exception
when the JRE calls Connection.close() on exiting the try-with-resources block.
3) If the error is session-severity, then Derby closes the connection. Nothing
happens when the JRE calls Connection.close() on exiting the try-with-resources
block. That is because Connection.close() is idempotent.
4) If the error is system-severity, then Derby shuts down the database. Again,
nothing happens when the JRE calls Connection.close() on exiting the
try-with-resources block.
Here are some additional suggestions:
Remove this paragraph:
"A session-severity or higher exception causes the connection to close and all
other JDBC objects against it to be closed. System-severity exceptions cause
the Derby system to shut down, which not only closes the connection but means
that no new connections should be created in the current JVM."
Reword the later paragraph:
"Note that a transaction-severity or higher exception causes Derby to abort an
in-flight transaction. But a statement-severity exception does NOT roll back
the transaction. Also note that Derby throws an exception if an attempt is made
to close a connection with an in-flight transaction. Suppose now that a
Connection is declared in a try-with-resources statement, a transaction is
in-flight, and an unhandled statement-severity error occurs inside the
try-with-resources block. In this situation, Derby will raise a follow-on
exception as the JRE exits the try-with-resource block. (For details on error
severity levels, see derby.stream.error.logSeverityLevel.)"
> Document use of Connection.close() with try-with-resources
> ----------------------------------------------------------
>
> Key: DERBY-5910
> URL: https://issues.apache.org/jira/browse/DERBY-5910
> Project: Derby
> Issue Type: Improvement
> Components: Documentation
> Affects Versions: 10.9.1.0
> Reporter: Kim Haase
> Assignee: Kim Haase
> Attachments: DERBY-5910-2.diff, DERBY-5910-2.zip, DERBY-5910-3.diff,
> DERBY-5910-3.zip, DERBY-5910.diff, DERBY-5910.stat, DERBY-5910.zip
>
>
> The Java SE 7 try-with-resources feature can cause problems with
> AutoCloseable objects like java.sql.Connection. You must be careful when
> writing portable code which declares Connections in the initializers of
> try-with-resources blocks, because Derby raises an exception if you try to
> close a Connection with uncommitted work in-flight.
> Changing Derby's Connection.close() to always commit in-flight work (and not
> raise an exception) would create backward compatibility issues, but we do not
> know yet how serious these issues would be, owing to a lack of data.
> Rather than change Derby's behavior now, we should document how Derby's
> Connection.close() behaves and describe the portability issues involved in
> declaring Derby Connections in try-with-resources initializers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
