Re: [Gnumed-devel] re commit

[Karsten Hilbert]

> I'm not sure if Karsten is agreeing with me, or just being condescending. 
Had to look that up. I simply cannot be condescending since I
don't hold any Higher Authority to condescend from.

> Here's a demonstration that a cursor from one connection doesn't 
> conflict with a cursor from a different connection.
I understand.

> In java, and in hibernate ( which is middleware to 10 different 
> relational database engines) , the semantics of
> one transaction / one session per connection holds. 
I am sure you are correct. I suspect, however, that this is
convenient semantics, not mandatory semantics.

> I can see the point one may want a shared connection amongst many 
> processes guaranteed to be read only, although I'm not sure about the 
> use of _ pseudo users to achieve it.
Well, the non-_* users simply don't have write access to
any tables. One would have to deliberately change session
credentials on a connection to be able to run updates/inserts
through it.

> As to why you may want many 
> cursors if you can't individual commit or rollback independent 
> transactions on them,
Well, IMO a cursor is but a "materialized query" or a query
with a (result) buffer. (I am not certain how to explain this
re update/insert queries.) Thusly it certainly makes sense that a
commit is on the connection and that it commits all currently
open cursors. Following a commit another transaction can be
started within the same connection.

> Othewise, I just thought cursors  was a cute way of focusing on what 
> one was doing at the time.
I guess, that's about the same in different words.

> What it shows below, is that cursor one deletes all the records in its 
> own transaction, but cu2 doesn't see that. After the deletion, cursor 
> one can see
> that the table is empty. But then it rollbacks the transaction. It then 
> sees the original table contents. cursor2 on the other hand, was not 
> affected by
> cursor one's transaction at all. If cursor one had committed, a select 
> by cursor2 would see the transaction.
Why am I not surprised ? I thought that'd be the way it worked ?

> Here's when I try to delete id=1 in cursor 2 , and then update in cursor 
> 1 where id=1  , and then as expected, the shell blocks,
> because cursor 2 hasn't been committed it's write, and cursor 1 won't 
> proceed until cursor 2 has committed or aborted (which it can't
> because the console is blocked in cursor 1 operation -->
By "console" do you mean "session"/"connection" ?

> deadlock  :   cursor2 waits for console to issue commit/abort , console 
> waits for cursor 1 return , cursor 1  waits for cursor2 commit/abort.
Wouldn't one get a serialization error here ?

> I'm sounding like Karsten with 101 transactions   ; )
That's good since I still need to learn more about
transactions and locking.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346