From:	Tim Bunce	Date:	Fri Dec  9 05:38:06 2005
Subject:	Re: Another feature request...

Much like my old catch phrase was "How does ODBC do it", my new catch
phrase is "How does JDBC do it?" - but sadly that doesn't help us much here
as Java doesn't have native support for coroutines.

So, my next new catchprase comes into play: "can it be implemented as a
subclass"?

Meanwhile, at this point, I'll flag it as a "nice to have feature"
for us to consider a little further down the road.

Tim.

On Fri, Dec 09, 2005 at 02:03:49PM +1100, Adam Kennedy wrote:
> 
> 
> Sam Vilain wrote:
> > On Thu, 2005-12-08 at 23:51 +0000, Tim Bunce wrote:
> >
> >>On Tue, Dec 06, 2005 at 01:57:58PM +1300, Sam Vilain wrote:
> >>
> >>>How about co-operation with coroutines (See the end of S17 in
> >>>pugs/docs/AES) in DBI v2 ?
> >>>
> >>>Of course it would be heavily driver dependent :).  But if there is
> >>>anything that DBI could do to be coro-safe, that would be cool.
> >>
> >>Can you expand on this with some practical examples?
> >
> >
> > How about "simple" to start off with.  This one launches three queries
> > "in parallel".
> >
> >  my $dbh = DBI.connect(...);
> >  $dbh.begin_work;
> >  my @coros;
> >  for (1..3) {
> >     my $coro = coro {
> >         my $sth = $dbh.prepare(...);
> >         $sth.execute;
> >         for =$sth -> $row {
> >             # process result...
> >         }
> >         $sth.finish;
> >     };
> >     $coro.ready;
> >     push @coros, $coro;
> >  }
> >  $_.join foreach @coros;
> >  $dbh.commit;
> >
> > Now, to understand this program, remember that a coroutine is a bit like
> > a thread, but it doesn't need another process or OS thread; instead it
> > uses defined preemption points.  Coroutines don't suck in practical use
> > like OS threads, because no matter how "lightweight" they are because
> > you still need to protect access to all common data structures with
> > locks, semaphores, etc.
> 
> Or in Perl 6, with Software Transactional Memory.
> 
> > The preemption points in the above are taken to be; the "join" (which
> > waits for a coro to finish), and all the $dbh and $sth operations.  Of
> > course the Coroutine API is not finished so I made up .join and .ready.
> >
> > If the DBD is capable of handling multiple statements with a single
> > database connection, then it could conceivably multiplex the execution
> > of the blocks as data is returned.  Otherwise, the first one's .prepare
> > or .execute will not return until the lock is freed by the $sth.finish
> > call.  It is not acceptable to open separate database handles, because a
> > transaction is open.  Then again, if the driver doesn't support
> > multiplexing, but supports cursors (and DBIv2 is capable of turning
> > selects into cursors when it needs to), then cursors could be used to
> > allow the parallelism.
> >
> > Does that explain much, or would something "practical" be better?
> 
> I would be interested in a real example of where this is useful. I'd 
> also like to know if any database in existance supports this, or plans to.
> 
> As for implementation (regardless of merit), since the main idea is to 
> encapsulate the larger chunks of functionality into Roles, I wouldn't 
> imagine it would be that hard to implement some form of 
> DBI2::Role::Cororoutine role...
> 
> Adam K