[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnumed-devel] re: commit

From: syan tan
Subject: [Gnumed-devel] re: commit
Date: Wed, 24 Sep 2003 03:36:33 +1000
User-agent: 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 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?)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]