Transactions – optional?

No. Transactions are not optional.

One of the things that irked me in learning Hibernate was the amount of time spent worrying about transactions. Indeed, when I speak about Spring/Hibernate implementation models to ColdFusion developers, I get the same reaction that I initially had myself – “Why do you keep talking about transactions? We know what they are, it’s kind of interesting, but this is hardly a central concern.”

Coldfusion database connections are in autocommit mode by default. The Hibernate guys wrote an excellent article on autocommit. Essentially it means you automatically get a transaction per <cfquery>.

This is a good thing. The CF server can’t possibly decide on a transaction strategy for you, so it can only do one of two things:

  • Turn on autocommit so you can get coding
  • Turn off autocommit so you must implement a transaction strategy before you can run a single query. Alternatively, you can work out how to turn autocommit back on.

Given ColdFusion’s RAD focus, which do you think CF is going to choose? It’s going to let you get coding.

Unfortunately, many of us take that as permission to put off thinking about a transaction strategy indefinitely. Can you actually put your hand on your heart and say “No, data consistency is not important to my application”? Probably not. But if you’re like me, you might be able to let your application slide across the line from prototype to production without really addressing this issue.

Hibernate, which is much more interested in being right than being RAD, starts from the other position. Work out your transaction strategy. Then we’ll talk. Autocommit mode is available if you really need it, but is off by default and is considered a non-standard usage model.

So no, transactions aren’t optional. Hibernate smacks you over the head with this fact, so if you’ve been letting this aspect of your applications slide, you’ve got some catching up to do.

Note: CF9 ORM in its default configuration does in fact choose the transaction-per-page-request strategy for you. This is a bit of a philosophical departure from the default cfquery behaviour, but I think it manages to walk the line between CF RAD culture and Hibernate “serious software engineering” culture.

3 thoughts on “Transactions – optional?

  1. Very interesting to read.

    I could be totally wrong, but IIRC, CFTRANSACTION’s start and end tags need to be on one page (possibly same template?). So it looks natural to me that CF9 ORM strategy is defaulted to transaction-per-page.
    Out of curiosity (might be very stupid question), can transaction span across multiple requests?
    e.g. session1 on request1, session2 on request2, finally flush them on request3…..

  2. There’s no requirement for CFTRANSACTION start and end to be in the same template. CFTRANSACTION is, however, bounded by the page request – if you haven’t closed the transaction by the time the request finishes, ColdFusion will close it for you.

    It is possible to have a Hibernate transaction span several page requests, but it’s generally a bad idea, as well as being a non-standard usage, which means you need to hack together a lot of the glue code yourself. See for example this approach for simulating a long transaction. I don’t necessarily endorse it, but it serves to illustrate the difficulties.

    Long transactions are usually a bad idea because they drive a truck through the principle that transactions should be as short as possible to avoid disastrous lock contention in the database. Some people think that a transaction-per-request is too long. Once a transaction spans multiple requests, you’re at the mercy of the user. They’ll be holding a lock on your database while they go and make a coffee.

    Oh, and I’m pretty sure transactions are always smaller than sessions. So no, you can’t hold open a transaction while you open and close sessions. The reverse is quite feasible – see the hibernate documentation

  3. Thanks for explanation.
    Yes it will be a bad idea.
    For some reasons, I just imagined one user app that gives several forms to save something, and that stupid question came out 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *