Bug 5760 - Spec should clarify that reader/write close() get called after exceptions
Spec should clarify that reader/write close() get called after exceptions
Status: NEW
Product: jbatch
Classification: Unclassified
Component: SPEC
All All
: P5 minor
: ---
Assigned To: ScottKurz
Depends on:
  Show dependency treegraph
Reported: 2014-01-31 16:07 UTC by ScottKurz
Modified: 2016-06-20 20:47 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2014-01-31 16:07:19 UTC

Comment 1 ScottKurz 2014-02-05 15:19:38 UTC
Added 'future' to whiteboard to consider idea of extending Closeable in a future release.
Comment 2 ScottKurz 2014-02-13 13:12:33 UTC
Not committing to address in future, just listing as candidates and pointing out they're excluded from current Maintenance Rel.
Comment 3 ScottKurz 2014-10-07 10:49:31 UTC
As I'm looking back on this now I'm realizing that I got too hung up on the idea that it was too late to start implementing Closeable (with idempotent close()).   We could have still considered saying this was the required behavior even without the interface to enforce this further.

For what it's worth, I'm almost positive the RI may call close() twice in some cases, for example if the writer close() throws an exception on certain paths we might retry to close both reader and writer.

Noticing this in walking through my fix for Bug 6259.
Comment 4 ScottKurz 2016-06-20 20:47:36 UTC
Another thing to clarify:  the diagrams in Section 11, showing reader and writer close() in a single transaction, could lead to some confusion.  E.g. if the writer close() throws an exception, and the tran rolls back, what does this mean for the reader?  Do we still call reader close()?  In what transaction?

This should be clarified.  Note that there are now several close()-related issues open (e.g. Bug 6456, Bug 7684) and it might make sense to tackle them together instead of via the current breakdown.