Hi Roger,

think I changed this behaviour between rc5 and rc6. Each RsIterator is associated a PB instance at creation time. So if you close the PB the RsIterator was no longer valid. On PB.close() the used connection will be closed (returned to pool). Thus all references to Statement or ResultSet in RsIterator will became invalid. The RsIterator has an open cursor to a ResultSet but the connection was closed.

The old version only worked because most user use connection pooling and the connection only was returned to pool instead of an effective connection close. But when DataSource was used this will cause problems.
The RsIterator now strictly close all resources before the associated PB instance
-commit
-rollback
-close
This fixed some additional problems in managed environments complain about unclosed ResultSet and Statement.


> In case 2, i can no longer access my data. All nested RsIterators have their
> resource released. And i have not found a way
> to prevent this from happening. ChainingIterator contains no logic to set
> the autorelease switch on all iterators.


You are right this is a problem, method 'setAutoRelease' is only defined in RsIterator. I will add this method to OJBIterator interface earliest in 1.1 (see comment in RsIterator#setAutoRelease), because changes in a top-level interface are not welcome in a RC. But in PagingIterator and ChainingIterator this method does not exist, so no cast is possible.
Would it help you if we implement 'setAutoRelease' in these classes?


regards,
Armin

Janssen, Roger wrote:
Hi,
I'm migrating from rc4 to rc6.
I now am confronted with the behaviour of RsIterator with its close binding
to a persistencebroker instance.
Case 1:
- 1. create persistence broker
- 2. issue a query, resulting in an java.util.Iterator.
- 3. close broker
- 4. do something with iterator
In this case the iterator might be an RsIterator, that is created in some
backend component (step 1 to 3), returned by this component and then given to a presentation layer where it
will be processed for display (for instance
Velocity engine processing velocity template to generate html code with the
iterator in its context).
However, i am not able to acess the data anymore!!!! Big problem i would
say.
The backend could set the autorelease switch to false, but that would mean,
that from within my presentation layer,
somehow i will have to implement a 'manual' resource release. This might not
be possible, and if it were possible, it is
kind of ridiculous to implement this kind of backend businesslogic in a
presentation layer.
Case 2:
- same as case one, but the resulting iterator is a ChainingIterator
In case 2, i can no longer access my data. All nested RsIterators have their
resource released. And i have not found a way
to prevent this from happening. ChainingIterator contains no logic to set
the autorelease switch on all iterators.
Of course the same issues of case 1 remain valid.
Am i overlooking something and/or doing something completely wrong and/or
have no understanding of this functionality
whatsoever????
Do i really have to explicitly release the resources on the RsIterator, what
happens if i do not?
As it is, i cannot access my data anymore using rc6.... that poses me for
some kind of a problem.
Thanx for any help on this issue,



Roger Janssen <mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED] iBanx B.V <http://www.ibanx.nl/> http://www.ibanx.nl Kon. Wilhelminaplein 13 tel +31-20-5727900 P.O. Box 69289 fax +31-20-5727901 1060 CH Amsterdam mobile +31-6-505 267 13 The Netherlands




*************************************************************************
The information contained in this communication is confidential and is
intended solely for the use of the individual or entity to whom it is
addressed.You should not copy, disclose or distribute this communication without the authority of iBanx bv. iBanx bv is neither liable for the proper and complete transmission of the information has been maintained
nor that the communication is free of viruses, interceptions or interference.


If you are not the intended recipient of this communication please return
the communication to the sender and delete and destroy all copies.


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to