Skip to main content

Viral Transactions

1 reply [Last post]
Joined: 2003-07-08

I think its pretty well established that we need some kind of support for transactions, even if we just defer that support to the server. There is one nagging issue with regards to transactions that I don't yet like, but see no way around. I was hoping somebody out there could help me out with this one :). The terminology I'm using here is based on my current incubator code.

A DataSource maintains a list of all of the DataModels associated with it. It is necessary to maintain this list because of the nature of transactions. A single DataSource can only be used within the context of a single transaction (whether that transaction is in auto-commit mode or not). Thus, each of the DataModels associated with the same DataSource must be within the same transaction. Also, DataModels can be arranged in a master/detail heirarchy. All of the DataModels within this heirarchy must be within the same transaction. However, since DataModels in a master/detail heirarchy may also be using different DataSources, it becomes necessary to walk the master/detail tree of all DataModels associated with a single DataSource looking for any other DataSources that must be moved over to the new transaction.

Setting the transaction for a DataSource is therefore viral since it will spread to other DataSource's when those other DataSource's have DataModel's mixed with the original DataSources DataModels in master/detail relationships.

Not very pretty, but while the alternative is attractive, it also limits functionality. The alternative of course would be to force DataModels in a master/detail relationship to all use the same DataSource. Simple enough, but it disallows some rather interesting applications, especially in the enterprise arena. For instance, being able to read basic employee information from one legacy database and binding it to a JList and part of a JForm, and reading detail information from a new WebService and binding that data to the rest of the JForm.

I don't like the viral nature of Transaction here because it could have unintended consequences and be the source for many bugs and much irritation among developers. But I don't see any way around it.


Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-02-17

Transaction support is going to be tough, no matter what. I think that the support on the client side can be somewhat virtual (we need only support the general idea of transations, not any specific Transaction API/Protocol). For the type of 'enterprise' application you're positing, I'd be willing to accept that customers that are developing that type of application will use an aggregation server to handle the transaction side, and that the client still need only communicate with one server.

It's very hard to do this solely via the client side: in a previous startup I worked in that played in this space, we defined our own web services protocol that included 'transaction' support in order to do multiple data sources/data models.