"Kevin Grittner" <Kevin.Grittner@wicourts.gov> Sunday 27 March 2011 18:55:58
> > Dave Cramer wrote:
> >
> > Adding to the list is statement timeout. I seem to recall the issue
> > is we do not want to spawn a thread for each statement which seems
> > to be the only way to do this. Alternatively we could use timers,
> > but I presume they just spawn threads as well.
>
> No, see the java.util.Timer docs:
>
> http://download.oracle.com/javase/6/docs/api/java/util/Timer.html
>
> Each Timer object uses one thread and can handle thousands of pending
> timers. If you're using JDBC you're on a JVM, and those all know how
> to multi-thread gracefully. A daemon thread for a group of timers
> should be no big deal.
>
> We had a patch submitted for this, which looked to me like it was
> pretty close to committable. I raised some concerns and was
> intending to look at it again, but haven't gotten the requisite round
> tuits yet.
>
> -Kevin
If I good catched thread.
I experimented with cursors, it's dead corner. Actually, if you have fetch
size setted then cursors are used, but PG doesn't support scrollable &
updatable cursors. From other hand about background fetching, You will need to
fetch some good amount of rows, because of, mainly, network latency. Let's
assume your latency is 2ms, and I'm looking for row witch id or something
(number value) is 2, Java construct if (rs.getInt(1) == 2) takes less then 2
ms. Query will take much longer. If you ask for 10 rows, query time is at
least 20ms - too bad.
If you wan't to add positioned updates, then it's same problem you may move
only forward.
The fetch size is for databases that supports, hmm, prefetach, when you may
download next xxx rows without moving cursor. I think PG can do it, but only
in PgSQL.
Regards,
Radek
