Front page | perl.dbi2.dev |
Postings from December 2005
Re: Another feature request...
Thread Previous
|
Thread Next
From:
Tim Bunce
Date:
December 9, 2005 04:38
Subject:
Re: Another feature request...
Message ID:
20051209123805.GB20787@timac.local
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
Thread Previous
|
Thread Next