request/reply in one MOM transaction

If in one transaction you send a request then read reply off the queue/topic, i think you will get stuck. With the commit pending, the send won’t reach the broker, so you the requester will deadlock with yourself forever.

An unrelated design of transactional request/reply is “receive then send 2nd request” within a transaction. This is obviously for a different requirement, but known to be popular. See the O’Relly book [[JMS]]

2 phase commit (2pc) — homemade "implementation" idea

Phase 1 — reversible, preliminary, try-commit.
Phase 2 — irreversible final commit.

During phase 1, the XA manager issues (over the network) the try-commit command to all resource (nodes).

* If one of them didn’t come back (perhaps after a timeout), manager issues rollback command to all.
* if all successful, it issues the final-commit command.

Phase 2 should be a very simple, no-fail operation. If a resource (node) can’t support/provide such a never-fail operation, then it can’t qualify for XA transaction at all.

Another disqualified resource — If a node crashes badly during Phase 1, then rollback may be impossible and data loss might occur — this resource doesn’t qualify for XA.

Q: is the XA mgr a separate process or just an “object” in the same VM as a resource?
A: a process on the network

Q: is the XA mgr a network daemon that can receive incoming messages? Is it a multi-threaded network server?

tibrv supports no rollback – non-transactional transport

Non-transactional “transports” such as TIBCO Rendezvous Certified and socket do not allow for message rollback so delivery is not guaranteed.  Non-transactional transports can be problematic because the operation is committed to the transport immediately after a get or put occurs, rather than after you finish further processing and issue a Commit command.

JMS does support transactional “transport”, so you can “peek” at a message before issuing a Commit command to physically remove it from the queue.

Oracle article on exclusive/shared locks, row/table level locks, non-repeatable-read

Here are a small sample of the knowledge pearls —

– If a transaction obtains a row lock for a row, the transaction also acquires a table lock for the corresponding table. The table lock prevents conflicting DDL operations (like alter table).

– A detailed comparison of read-committed vs serializable isolation levels in Oracle

To my surprise,

* “Readers of data do not wait for writers of the same data rows”. Maybe Reader thread simply goes ahead and read-committed. Reads either the BEFORE or the AFTER image of the row. Now, If isolation is at Serializable, then still no wait, but this thread will throw exception if it re-reads the row and detects update. This is a classic non-repeatable-read error.

reader/writer lock concept simplified, using counting semaphore

Invariant to be enforced (Ignore the how-to-enforce please) — if a (exclusive) writer is in the critical section, then no other (reader/writer) thread should be seen in the same critical section.

Now a possible enforcement policy — using semaphore with a large number of permits. Any reader must get a permit before entering critical section; a writer must get all permits before entering.

We can learn a lot from DB transaction isolation levels.

transaction isolation levels, again has more details

This article shows simple but clear examples — One of the best articles on isolation levels.

Before seeing this article, I studied isolation levels 3 times until I got them right.

If you are CEO (or ticket master) of Northwest Airlines, a repeatable-read isolation level will assure a traveler “what you see on screen is available for the next 10 seconds”.
However, most Sybase systems default to one level lower – Level 2 i.e. read-committed.

nested transactions in sybase

If proc1 does “begin tran; exec proc2”, and proc2 does a “begin tran…”, how many transactions are active at that point? The way to test it in sybase is simple, open a session in sqsh, isql or aqua studio and

insert t … — a table
begin tran tr1
insert t…
commit tr1

— open another session and revoke insert permission

insert t… — causing an error and a rollback

— now see what’s rolled back.

why JMS session is single-threaded

1 session – 1 transaction.

How about database connection. 1 connection – 1 private memory space in the server to hold transaction data, so no multiple concurrent transaction. Even a select is part of a transaction, if you recall the isolation levels (repeatable read…) Usually, the same connection is not used in multiple concurrent threads, but no system enforcement.

How does any JMS system enforce the single-threaded rule? I doubt there’s any. If you break the rule, then result is perhaps similar to the c++ “undefined behavior”.

Note a Connection can be shared by threads, but a Session can’t. The java tutorial says “You use a connection to create one or more sessions.” Additionally, in the flow diagram anything upstream is thread-safe; anything downstream is single-threaded.

connFactory -> Conn -> Session -> producer/consumers