Jonathan pointed me to a recent discussion on TSS concerning writing transactional resources for non-transactional objects. It expanded into the more general topic of how to write XAResources, which it topical at the moment within Red Hat. Anyway it got me thinking that many of these requests aren't necessarily for "How do I write an XAResource?" but more for "How do I make my data transactional?" These are two different questions: the former infers the latter, but the latter doesn't infer the former. Yes believe it or not but transactions existed before XA came on the scene.
So it got me thinking and I realised that what many of them they really want is something akin to what we did in the original Arjuna system. It didn't have a name back then, since it was the whole reason for doing the Arjuna research, but eventually it became known as Arjuna Integrated Transactions (AIT), or Transactional Objects for Java (TOJ). The use of "it" has not been pushed much (at all) over the past few years, which is a shame because I still think it's a great model. So it may be time to dust it off and bring it back into the light.
Subscribe to:
Post Comments (Atom)
4 comments:
That's kind of funny, as I was just reading up on this:
http://www.jboss.org/jbosstm/
It looks to be alive and well there.
It's been buried in the JBossTS releases since the start, since it wasn't quite core to what we needed in JEE-land. But I'm digging it out now.
TOJ are well suited for short lived transactions. How do you see TOJ compared to an object storage library (such as Berkeley DB-JE) for working with persistent objects? I know additional index files can be created and new implementations for ObjectStore added, but would you choose this road (now)?
Yes, because TOJ supports nested transactions they can be used for longer duration interactions. They were also used as the building blocks for OPENflow, a long running workflow system that we developed many years ago. Plus when we were working with IBM on the OMG Activity Service, the implementation of that we used had some extensions to TOJ to allow them to support different levels of data granularity. They also (phew!) support type specific concurrent control which is useful for long duration interactions with lots of data sharing.
Post a Comment