Is the relentless pursuit of Transactionality and ACID properties always warranted?

``We can but wait and see, sir. The tie, if I might suggest it, sir, a shade more tightly knotted. One aims at the perfect butterfly effect. If you will permit me—'' ``What do ties matter, Jeeves, at a time like this? Do you realize that Mr. Little's domestic happiness is hanging in the scale?'' ``There is no time, sir, at which ties do not matter.'' (From "Jeeves and the Impending Doom" by P G Wodehouse)

"Some Enterprise Architects become over-fastidious, rather like Jeeves and his high standard for ties, in their pursuit of Transactionality and ACID properties."

Enterprise Architects with background in Financial Services or Enterprise Resource planning applications, sometimes overdesign systems for "Transactionality" and "ACID" properties, even when clearly not required. An edge case is using standard enterprise paradigms like Oracle RAC and a design that preserves ACID properties in the context of Internet facing applications. Most Internet companies use architecture that does not promise ACID properties or fault tolerance., under most situations. This allows them to achieve high scalability at affordable cost.

For example: Consider a presence server application. A Presence Server is used by Internet/Extranet Chat Applications, to indicate presence and other information abut the users. A "Presence Server" shows presence of a user to other users, such as the user's chat client buddies.

Skype for example shows 11,490,185 users logged in right now. All of these users have contact information and call history stored online. When a person logs into Skype, he/she wants to see other connected users in his/her contact list immediately, but not necessarily instantaneously. Presence servers, are also expected to be an important and growing part of corporate applications.

One possible solution for scalability is to use "Weblogic JDBC multi-data source". A change in the status of a user is reflected in one Oracle database. The change in the Oracle database, results in "Changed data set" message being created on an Oracle AQ Queue. The messages created in Oracle AQ are routed using an ESB to all of the different databases. A PL/SQL script (I think) can also propagate the changes to multiple databases. Another approach is CDC (Change Data Capture) subscription on all the databases. This last approach I think is the most scalable approach.

Click here for the high level architecture diagram.

Typically, multidatasources are used to configure Oracle RAC (Real Application Clusters) . However, there is no reason to have non-RAC databases in multidatasource. Transactionality and ACID properties will not be preserved, but this design may still meet less demanding requirements, for numerous Internet as well as Enterprise applications. .

Some systems which could be designed to be with Oracle standard edition one, may be using an expensive Oracle RAC configuration. The system shown in the high level architecture diagram may be equally or even more scalable at a fraction of an Oracle RAC based solution. With Oracle Standard Edition One being listed at 5,800 dollars, and Oracle RAC license list price at 80,000 dollars, the approach described here has both technical and monetary virtues- and perhaps even spiritual ones.

For Avarice is a sin, as depicted in the painting below.

1909 painting The Worship of Mammon by Evelyn De Morgan.

(As Bertram Wooster would put it, "I will be deceiving my public" -were I to claim that all issues involved in using WebLogic Multidatasource have been considered here. For example, How to bring a database down, and how to rebalance connections when a failed node rejoins the pool, how to cause failover when a database is overloaded, how to detect an imbalance of connections in the nodes of the multipool, how to gracefully restart failed nodes, whether a master database is needed, how to clean the data corruption that might happen, and so on….)