See post on “variability”, the 4th V of big data.
A noSQL software could support transactions as RDBMS does, but the feature support is minimal in noSQL, according to the Oracle noSQL book.
Transactions slow down throughput, esp. write-throughput.
In a big data site, not all data items are high value, so ACID properties may not be worthwhile.
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]]
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?
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.
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.
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.
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.
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
— open another session and revoke insert permission
insert t… — causing an error and a rollback
— now see what’s rolled back.
* put “begin tran” into a Statement. Most basic. Even in a web server app (EOS), you could use this.
* JDBC transaction api. About as basic as “begin tran”.
* hibernate offers a transaction API. No “server” needed — you can use hibernate in an one-class application.
* J2EE servers offer the JTA api.
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