Re: Cross-application transactions in middleware systems

vadim tropashko <vadim_member_at_newsranger.com> wrote:
: I have related question: what degree of isolation a typical TP monitor
: provides?

I'm not too sure; I haven't had the need to employ one yet.

: As original poster noted, different database vendors take very different
: approaches to isolations. For example Oracle isolation levels are
: different from ANSI standart -- Oracle is not using read locks by
: default, so that Oracle's serializability is slightly weaker than ANSIs,
: for example. While it is probably possible to ensure consistent

I have to differ with this statement. Oracle has serializable transactions, same as ANSI; I spent a lot of time in Postgres screwing with transaction isolation levels, so I know the standards. I think you misunderstand Oracle's MVCC. Read locks aren't necessary, because an open transaction reads segments dated from the time the transaction started. If someone commits an UPDATE in the middle of said transaction, data subsequently read by the transaction will remain unchanged -- so no need to lock for reads. Final analysis? Fewer deadlocks; still provides serializable isolation level.

: isolation level across databases by manual locking, the question is
: whether TP monitors really care about these subtleties.
: After all, 2-phase commit is very small portion of TP fuctionality, among
: terminal management, batch processing and other facilities inherited
: from cobol era...
 

: In short, transparent gateways might be simpler solutions to the problem (in
: that case your expenses are no greater than the sum of database licences;-).

Good point. I don't know how TP monitors handle read locking; and I hadn't considered the mainframe leftovers. In any case, I think adding these issues onto the rest of her project wouldn't be a choice I would make. (Being forced into it, more like.) Received on Wed Mar 28 2001 - 03:25:02 CEST