[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re commit
Re: [Gnumed-devel] re commit
Tue, 23 Sep 2003 14:15:42 +0200
> 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.
> 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
> 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.
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346