|Subject||Re: jabird / Select / Update|
> to the server to re-prepare. And as updatable resultsets are a fact andThat does not mean they are the most effective thing.
> 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
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).reading through never-closing read-only transaction and applying updates via aux short read-write transactions.
> I am not sure what you mean with 'bi-transactional' work and why
> 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 suchPity. Maybe it would nice to implement.
> thing in Jaybird when using a single connection, so you don't have
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 Rotteveel