[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] re: commit
[Gnumed-devel] re: commit
Wed, 24 Sep 2003 03:36:33 +1000
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313
Reading the responses, I think everyone agrees
1) transactions are one per connection for any point in time.
2) serial transactions can be issued per connection, through different
3) it's not convenient to call "commit" everytime one gets a cursor
object from a connection,
just in case somewhere else in the code, the intention was to execute a
4) mainly multiple threads sharing the same connection object and
getting different cursor objects
are likely to produce concurrent transactions which could potentially
interfere with each other
, especially if abort is called in one thread.
(Maybe that's why hibernate made session objects thread local objects,
so this could not occur).
5) A single thread at different places in the code can only interfere
if a commit or abort isn't called at the end of the block of code. If
an abort is called,
previously created cursors' writes should persist if commit had been
called at the end of their usage.
Since, the code is single threaded, then by issuing commit or abort
after every usage of cursor should
make the prospect of cascading aborts unlikely, so it wouldn't be all
that imperative to use readonly pseudo users
to protect against hacking. On the other hand, sloppy coding by us ,
forgetting to commit our writes,
would be vulnerable, but hell, that would be admitting we're all hackers
anyway (just about as bad as software
companies admitting they employ students to do innovative or substantial
work at low cost).
The problem of obtaining a connection outside of the API would seem to
be mainly if the updates weren't according to the
domain intentions; a separate connection would mean a separate
transaction, so if any outside writes were conflicting,
their connection would block, until earlier inside writes had finished
The connection pooling reason seems to be a valid reason for
indirecting the dbapi calls if the intention is to have
multiple threads, but for a single thread I can't see the necessity;
just hold onto one connection object for the duration
of the client, and enforce commits after writes. On the other hand,
server side connection pooling does make sense, but
when has gnumed had server-side remote invocation objects ?
(I'm beginning to sound like that guy John Dooley from GPCG, -- .NET
is a new technology that we should be employing ... er?)
- [Gnumed-devel] re: commit,
syan tan <=