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.