Recently, I’ve noticed more and more people looking for ways to create massively scalable applications. It is no well known that the database is more often than not the bottleneck. This is why caching became ubiquitous these years with lots of products available on the market, both open source or not.

Unfortunately, there are cases where caching is not enough: either because even with exceptional cache efficiency (98% cache hits or more) or because your application isn’t read-mostly, ie: when there isn’t a ratio of at least 50 reads per 1 write. In the latter case, a write will invalidate the cache entry and will seriously reduce the cache efficiency.

In those cases (but there could be others), the only way to make your application scale is to make the database scale. Databases clusters like Oracle RAC or MySQL memcached will help you to some extent but sometimes even those won’t be sufficient and that goes without saying that this solution is incredibly expensive.

One of the alternative designs proposed is called database shard. The basic idea is to divide your data between multiple cheap servers, each one handling a small fraction of your data. This allows near-linear cheap scalability of your database cluster as you just have to make data separation a bit finer each time you want to add more servers. Here is a good article explaining the concept in more details. Big names like Google, Flikr and LiveJournal as using this technology as of today so this isn’t something to come but already present and working in production environments.

In the Java world, there are at least two good products to build shards: Hibernate using Hibernate Shards and OpenJPA using Slice. Both are JPA implementations that are going to split the data between all you database nodes with only a matter of configuration and maybe a bit of extra code.

One of the problem with shard that I noticed is often not openly discussed is that since the data is split across many databases, you can loose atomicity as your application might read or write to multiple data sources in a single transaction.

Well, that’s counting without that good ol’ technology invented more than 20 years ago: 2PC / XA and its related Java standard: JTA. Thanks to the two-phase commit protocol, the atomicity of the transactions can still be preserved.

If you’re looking to cut costs this could also be a good alternative to expensive traditional clusters. The two shard stack I mentioned are open source and there are at least two open source databases with good XA support you can use for your backend: PostgreSQL and FirebirdSQL.

Isn’t it a bit ironic that a technology regarded as one of the worst database speed hogs allows for massive database scalability ?

The long overdue BTM release candidate just made it out today, at last ! The project is still alive and kicking, it’s just that it’s like me: on vacation and needing rest.

A lot of bugs have been fixed in that new release candidate, mainly in the core transactional engine and all lately opened bug reports and feature requests have benn fixed / fulfilled.

This version should be very stable since it already passed near production quality testing but no software is ever tested enough so I’ll go on with that task for the coming days. My hard target is to release 1.3 final in the first week of August the latest. The end of the tunnel is close !

Finally, I want to thank everyone who helped me in this task be it by testing BTM, reporting bugs and requesting useful new features. Thank you, the BTM community.

It’s been nearly six months since BTM 1.2 has been released. A successful project should be releasing often, at least more often than once every six months. This is something I will need to improve with future versions: less new features but shorter release cycle.

Recently the community has been growing steadily even if the users mailing list does not reflect this. It seems that people prefer to contact me directly. I don’t have a problem with that but it makes the project feel unactive while this is absolutely not true.

To cut a long story short, a lot of newcomers sent me comments, reported bugs and asked for new features. I want to make everyone happy if I can so I don’t feel like answering back sorry, please wait until the next release especially when the release cycle is so long.

The feature I like most in 1.3 certainly is the embedded JNDI provider. Thanks to it it is now possible to use BTM only with standard API: only JDBC, JMS, JTA and JNDI APIs are needed to access the transaction manager and its connection pools, be it when running in a standalone JVM or when embedded in a servlet container like Tomcat. The only non-standard required call left is to bootstrap the transaction manager. While this is taken care of by Tomcat when both are integrated or by Spring if you happen to use it there is still a gap if you just want a bare bones JTA implementation. Nevertheless I think this should satisfy Christian Bauer.

there is no configuration parameter needed to activate this mechanism.

it consumes zero resource when not used.

it can work in parallel with any other JNDI provider.

all resources (JDBC and JMS) are available under their unique name.

the user transaction is available by default under the standard name

Obviously, any framework or library that can get those resources from a configurable JNDI provider can take advantage of this feature. A good example is Hibernate. I just hope this feature will ease integration with all frameworks that can take advantage of an JTA implementation

I’ve been really busy with many different things lately and this caused delays in the release of BTM 1.3. Hopefully I will be able to release the second beta in the coming days and the final version shortly after, my plan being for the end of this month.

Some of the most interesting features that will take place in this release include:

The long-awaited incremental recovery that will allow you to register your resources (JDBC datasources and JMS connection factories) even after the transaction manager startup will finally be part of this release.

A serious redesign of the internal 2PC engine that is now able to even better report errors happening during 2PC while at the same time bring enough flexibility needed by features I plan in future releases.

A JNDI provider is now embedded in BTM. It allows you to access the TM and all of its configured resources using fully standard API without a single extra line of configuration.

This doesn’t sound like much but 1.3 is quite an important milestone and might very well be the latest of the 1.x series. I really want to get that version heavily polished and very well tested before moving on to the Next Big Thing.