> Well, the proposal of implementing it like holdable cursors means using
> a Materialize node which, if I understand correctly, means taking the
> whole result set and storing it on memory (or disk).
Would it help to hold the lock for a record that is the current cursor position,
iff this record
On Tue, Jul 06, 2004 at 08:45:52AM +1200, Oliver Jowett wrote:
> Buffering *all* the ResultSet data client-side isn't an option --
> cursors are used specifically to handle resultsets that don't fit into
> heap on the client side. And implementing a disk cache or similar a)
> doesn't work if yo
On Tue, Jul 06, 2004 at 08:45:52AM +1200, Oliver Jowett wrote:
> This is a non-starter for JDBC: it has no control over when an
> application decides to access a ResultSet in a way that results in a
> FETCH of new data.
>From what you're telling me, I'm not sure I like JDBC! Why did they com
Jeroen T. Vermeulen wrote:
That makes me wonder why people want to maintain transactionality w.r.t.
nested transactions but not with "outer" ones. Odd!
Yep.
But then the FETCH should still occur before the transaction as far as I'm
concerned. You fetch a batch (if it fails, you terminate) and *tr
