[Gnumed-devel] re: commit

[syan tan]

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 
cursor objects.
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 
tentative transaction;
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 
its transaction. 
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?)