> to the server to re-prepare. And as updatable resultsets are a fact and
> clearly defined in the JDBC spec, I don't think we should consider it as
> second-rate. That said, there are probably more important things to
> consider.

That does not mean they are the most effective thing.
They are already supported and i think that there to be clear documentation like "gotha's and quirks" concise page/section, that while this works, for massive changes another approach is strongly recommended.

> > You would probably loose ability of bi-transactional work (while you can add some auxUpdatingTransaction field you would hardly make it reliable in all those automagic scenarios).

> I am not sure what you mean with 'bi-transactional' work and why

reading through never-closing read-only transaction and applying updates via aux short read-write transactions.

> changing resultset would make you loose that ability.

That only works with strict condition on primary transaction, if user would change it's parameters that would cause all kinds of troubles: deadlocks, invisible changes, whatever.

> There is no such
> thing in Jaybird when using a single connection, so you don't have

Pity. Maybe it would nice to implement.
Though this strategy may work via two connections as well, though less elegant.

> that now when using updatable resultsets.



> > So while this can be cached, IMHO in this regard "faster" means really "worse".
> >
> > ----
> >
> > I'm curious if JayBird could provide special kind of JDBC transaction splitting into two FB Transactions under the hood ? :-)
>
> Technically we probably could as Firebird allows for it, but as JDBC
> doesn't provide an API for that, I think it would be a relative waste of
> time. I'd prefer getting a more complete and correct implementation of
> JDBC before considering gold-plating the driver with all kinds of
> Firebird specific extensions.
>
> Mark
> --
> Mark Rotteveel
>