0

http://www.itjobswatch.co.uk/jobs/uk/cics.do

http://www.itjobswatch.co.uk/jobs/uk/tuxedo.do

Look at the demand for programmers (% of job ads that the keyword appears), first graph under the table. It seems like demand for CICS, Tuxedo has fallen from 2.5%/1% respectively to almost zero.

To me, it seems bizarre: now we have more networked and internet enabled machines than ever before. And most of them are talking to some kind of database. So it would seem that use of products whose developers spent last 20-30 years working on distributing and coordinating and optimizing transactions should be on the rise. And it appears they're not.

I can see a few causes but can't tell whether they are true:

  1. we forgot that concurrency and distribution are really hard, and redoing it all by ourselves, in Java, badly.

  2. Erlang killed them all.

  3. Projects nowadays have changed character, like most business software has already been built and we're all doing internet services, using stuff like Node.js, Erlang, Haskell. (I've used RabbitMQ which is written in Erlang, "but it was small specialized side project" kind of thing).

  4. BigData is the emphasis now and BigData doesn't need transactions very much (?).

None of those explanations seem particularly convincing to me, which is why I'm looking for better one. Anyone?

Improve this question
2
  • 3
    Doesn't really have to do with Erlang or Haskell, but Microsoft has already solved this problem with MSDTC so that pretty much universally solves the transaction problem on the MS stack.
    – maple_shaft ♦
    Commented Mar 26, 2012 at 15:50
  • I think it has something more to do with CICS and Tuxedo being expensive. In Java there are JTA implementations already, and application servers implement transaction manager/coordinator functionality. For the newish NoSQL databases, some like Neo4J have transactional capabilities compatible with JTA, while other NoSQL systems have finer grained update mechanisms (like single row locks) but may not have traditional transaction functionality like you get with an RDBMS.
    – wkl
    Commented Mar 26, 2012 at 20:34

2 Answers 2

Reset to default
2

Transaction Monitors are still all the rage, its just that "Websphere", "Weblogic", "JBOSS" and "GlassFish" are now the dominant brand names!

Or to put it another way the decline of CICS and Tuxedo is a symtom of the decline in COBOL and plain C as application languages. The rise of J2EE (Application containers are really transaction monitors!) is a reflection of the rise of Java as the language of big business.

Improve this answer
2

First of all, there are more alternatives:

  • MSDTC (Microsoft Distributed Transaction Coordinator) — available since Windows 2000;
  • various implementations on JTA (Java Transaction API), including open-source such as JBossTS;

Second, there is much more emphasis on building decoupled, scalable systems. Thus instead of transaction you have message queues. Distributed transactions just don't scale well enough. It's about Eric Brewer's CAP theorem. With traditional transaction monitors you choose consistency & availability, while truly scalable systems need availability & partition tolerance, sacrificing consistency for eventual consistency.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.