[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] re: non-serializability detection
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] re: non-serializability detection |
Date: |
Wed, 19 Jan 2005 15:35:22 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> at least they could say "tsk, tsk, this comes up every x months or so;
> please see ... <href>" which is both patronizing , yet politer ;)
Sure, but I agree I should be able to figure this out. Since
the database isn't designed to support my *business* logic needs
I obviously need to take proper precautions when following
business requirements.
> what I get is the ability to read committed updates of other transactions,
> when I set ... serializable ;
> this makes it no different from set trans. isolation read committed , or
> what am I missing?
I don't think I understand the difference well enough to
decide we can really go with the weaker isolation level. Hence
I decided to code for the stronger one.
> actually, what I don't like is how unportable using xmin seems ,
That is, in fact, the most valid argument against what we are
doing now.
> what if someone wanted to use maxdb or firebird instead?
They need to write their own client.
There's a few other places where we aren't as portable as one
would wish.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
- [Gnumed-devel] re: non-serializability detection, catmat, 2005/01/17
- Re: [Gnumed-devel] re: non-serializability detection, catmat, 2005/01/18
- Re: [Gnumed-devel] re: non-serializability detection, catmat, 2005/01/18
- Re: [Gnumed-devel] re: non-serializability detection, Karsten Hilbert, 2005/01/19
- Re: [Gnumed-devel] re: non-serializability detection, Karsten Hilbert, 2005/01/19