Nerd Notes

/dev/brain: no space left on device

Archive for March 2007

Basic transactions in Spring using TransactionProxyFactoryBean

with 25 comments

UPDATE – Aug 29, 2011: I see that quite a few sites link to this article. Please keep in mind that I wrote this at the beginning of year 2007. While it should still be valid, more recent versions of the Spring Framework have largely simplified the approach described here and the online documentation about transaction management is far more complete, precise and straightforward than what I wrote years ago. I strongly encourage you to read the Spring documentation for the most up-to-date details.

Scenario: you have a simple stand-alone java application which accesses a single database using spring DAOs and you want to make your application’s interface transaction aware.

Now, while there’s plenty of ways to achieve this, the fool-proof, working approach is to make use of Spring’s declarative transactions and the TransactionProxyFactoryBean.

Here is an example BeanFactory configuration file:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:tx="http://www.springframework.org/schema/tx"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:aop="http://www.springframework.org/schema/aop"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/tx
http://www.springframework.org/schema/tx/spring-tx.xsd
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop.xsd"
>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost/foobardb"/>
<property name="username" value="dbuser"/>
<property name="password" value="dbpass"/>
</bean>
<bean id="fooDao"
class="com.acme.backend.dao.FooDAOJdbc">
<property name="dataSource" ref="dataSource"/>
</bean>
<bean id="fooBarServiceImpl"
class="com.acme.backend.FooBarServiceImpl"/>
<bean id="txManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>
<bean id="foorBarService"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager" ref="txManager"/>
<property name="target" ref="fooBarServiceImpl"/>
<property name="transactionAttributes">
<props>
<prop key="get*">PROPAGATION_SUPPORTS,readOnly</prop>
<prop key="*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>
</beans>

Okay, this was a lot of configuration data but, don’t worry, we’ll get into each little bit, one at a time and, by the end of this article, you’ll have all figured out.

In the first part, you basically have a boilerplate xml declaration of the required schemas. Those are needed so that your xml editor knows how to do auto completion and so that, when the xml configuration file gets parsed, the parser knows what is syntactically and semantically correct and what’s not.

Then you have a datasource bean declaration:

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver"/>
<property name="url" value="jdbc:mysql://localhost/foobardb"/>
<property name="username" value="dbuser"/>
<property name="password" value="dbpass"/>
</bean>

This simply declares a configuration object with the datasource properties, which are the usual driver class name, connection URL and login credentials to the database. If you look closely, you’ll see that I’m using a commons-dbcp BasicDataSource. This means two things:

  1. the connections you’re going to get from this datasource are going to be pooled by the commons-dbcp driver
  2. you’ll have to put the commons-dbcp and commons-pool jars in the classpath

The next piece is quite simple:

<bean id="fooDao"
class="com.acme.backend.dao.FooDAOJdbc">
<property name="dataSource" ref="dataSource"/>
</bean>

This declares a DAO, plugs in a jdbc implementation class for it and injects the datasource as a property of the DAO.

<bean id="fooBarServiceImpl"
class="com.acme.backend.FooBarServiceImpl"/>

This declares the service implementation. In other words, this is the bean that implements the interface to our application. It is here merely because we need to declare a placeholder we’ll use in the transactional proxy declaration later.

<bean id="txManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>

Here we have declared a transaction manager using Spring’s default DataSourceTransactionManager. Then, we inject the datasource property into the transaction manager bean so that it becomes aware of what it should operate upon.

<bean id="foorBarService"
class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<property name="transactionManager" ref="txManager"/>
<property name="target" ref="fooBarServiceImpl"/>
<property name="transactionAttributes">
<props>
<prop key="get*">PROPAGATION_SUPPORTS,readOnly</prop>
<prop key="*">PROPAGATION_REQUIRED</prop>
</props>
</property>
</bean>

This is a bit more complicated and needs some careful explanation. The bean we’re declaring here is a transaction proxy, a class provided by Spring which takes care of wrapping the service implementation with a transactional behavior.

The transaction proxy needs a few properties set. Let’s see what they are:

  • a transaction manager (remember we had declared that earlier, hadn’t we?)
  • a target class; this is the class that the proxy wraps and adds transactional behavior to
  • the transaction attributes

The transaction attributes are a set of properties. They describe what the transactional behavior should be. In this very simple but effective example, we are declaring that all methods of our service interface beginning with the name get are to be considered read-only and that they support transaction propagation. The other methods are considered as write methods in terms of transaction behavior and they require transaction propagation.

Now you’re gonna ask me: “And all of this is for what?”. Well, what you achieve with this kind of configuration is a fully transactional service. That means, if something goes wrong within your service operation, all you have to do is throw an exception and the Spring framework (and your database) will take care of rolling back all work.

For a simple, standalone application, this is just great. With a few lines of xml configuration data, you’ve got a fully transactional service. Ain’t that great? If you think it’s not, then you must take a long walk with an Oracle architect.

Written by Mirko Caserta

March 30, 2007 at 11:09 am

Backing up a vmware virtual machine

with 5 comments

I’ve learnt quite a number of new things today. One of these things is that an ISO9660 filesystem doesn’t allow files bigger than a couple of gigabytes. Another thing is that bzip2 kicks ass, even if it actually doesn’t implement the best compression algorithm available today (your milage may vary).

Another interesting thing is that the good old cdrtools package on Gentoo sucks. In my understanding that’s mainly because of licencing issues which came out during the software development. But, no worries, the new cdrkit ebuild has a modern cdrtools implementation with a compatible interface. That is, the good old mkisofs and cdrecord command lines you (and your GUIs) had learnt how to use are just the same. Different software, same interface. Great, uh? So, first of all, if you want the latest tools on a Gentoo box, you’ll need to:

# emerge -C cdrtools
# emerge -av cdrkit

Anyway, my job today was to backup on DVD-R media a large vmware virtual machine in order to regain free storage space on a server with serious shortage troubles. To begin with, we have a directory which holds the VM (virtual machine) files:

# du -sh my-very-cool-vm
21G my-very-cool-vm

Now, 21 gigabytes of data is a lot because this VM hosts a few extra virtual disks. But, if you’re lucky enough like me, some bzip2 goodness might help:

# tar cvf - my-very-cool-vm | \
bzip2 --compress --verbose --best --stdout > \
my-very-cool-vm.tar.bz2
# ls -lh my-very-cool-vm.tar.bz2
total 4.3G
-rw-r--r-- 1 root root 4.3G Mar 8 15:32 my-very-cool-vm.tar.bz2

Depending on your iron, the time between tar and ls might be enough for you to gain a few extra golds in World of Warcraft. Anyway, now that might actually fit on a DVD-R. But, since there’s a 2GBytes file size limit on ISO9660 filesystems, we still need to do a little something before we can fire up mkisofs. Our old unix friend split comes to the rescue:

# split -b 1024m -d my-very-cool-vm.tar.bz2 \
my-very-cool-vm.tar.bz2-part-
# rm my-very-cool-vm.tar.bz2
# ls -lh
total 4.3G
-rw-r--r-- 1 root root 1.0G Mar 8 16:04 my-very-cool-vm.tar.bz2-part-00
-rw-r--r-- 1 root root 1.0G Mar 8 16:05 my-very-cool-vm.tar.bz2-part-01
-rw-r--r-- 1 root root 1.0G Mar 8 16:05 my-very-cool-vm.tar.bz2-part-02
-rw-r--r-- 1 root root 1.0G Mar 8 16:06 my-very-cool-vm.tar.bz2-part-03
-rw-r--r-- 1 root root 295M Mar 8 16:06 my-very-cool-vm.tar.bz2-part-04

This is just perfect. Assuming the above files are in a directory called mydir, I can now run mkisofs like this:

# mkisofs -o dvd.iso -r mydir

This creates a file which holds the ISO9660 filesystem that we can later feed to cdrecord. My peculiar incantation for cdrecord is as follows:

cdrecord -v dev=/dev/hdc driver=mmc_mdvd -sao dvd.iso

Written by Mirko Caserta

March 8, 2007 at 4:54 pm

Windows shares in /etc/fstab

leave a comment »

Ok, this is pretty much an easy one, but I keep forgetting what the heck you need to specify in your /etc/fstab in order to mount an smb share (at least on a Linux system). Here is an handy example:

//host.lan/sharename /mnt/host/sharename smbfs defaults,rw,noauto,username=scott,password=tiger,uid=myuid,gid=mygid 0 0

All of the above needs to be on one line. Of course you need to replace a few things:

host.lan
hostname or ip address of the host you’re connecting to
sharename
the windows share name (pretty easy, uh?)
/mnt/host/sharename
a local directory where the share is to be mounted (this must exist before mounting so “mkdir -p” it)
username
the windows share username
password
the windows share password
uid
the user id the filesystem needs to be mounted as; this can be either numeric or symbolic and is usually your day-to-day user account
gid
the group id the filesystem needs to be mounted as; this can be either numeric or symbolic and is usually your day-to-day user account’s primary group

Once you’ve added that line into /etc/fstab, you can simply:

# mount /mnt/host/sharename

Written by Mirko Caserta

March 2, 2007 at 5:19 pm