How to manage transaction for database and file sy

Question

I store file’s attributes (size, update time…) in database. So the problem is how to manage transaction for database and file.

In a Java EE environment, JTA is just able to manage database transaction. In case, updating database is successful but file operation fails, should I write file-rollback method for this? Moreover, file operation in EJB container violates EJB spec.

What’s your opinion?

Answer 1

JTA is not simply for Databases, it can be used long with any other resource if that resource supports XA transaction. For example, XADisk enables one such integration of file-systems with XA transactions. Hence, it can also solve the problem of file-system and database consistency which you have been trying to solve.

Hope that helps.

Nitin

Answer 2

manually. You'll probably need to write compensatory transactions for this.

Answer 3

Maybe have a look at commons-transaction for transactional file access. Refer to:

• Transactional File System in Java
• An XA Filesystem
• An XA Filesystem, update

In any case, you'll have to write files outside the EJB container or to interact with a JCA connector as pointed out by @ewernli.

Answer 4

Access to external resources such as a file system should ideally go through a JCA connector. Though there are several posts around discussing this, I never found a ready-to-use JCA connector for transactional access to the file system, so I started to write one:

• Have a look at: JCA connector: a file system adapter. It's fairly basic, but manages commit/rollback of files.

Regarding other projects:

• I don't know the exact status of commons-transactions, it seems dead to me.
• Have a look at JBoss Transactional File I/O, looks promising.
• Have also a look at Filera: File resource adapter, but I don't think it's transactional

Note that as soon as you have more than one transactional participant, the app. server really need to use distributed transaction and things get more complicated. You must not underestimate this complexity (e.g. database have another timeout mechanism for distributed transaction).

Another lightweight approach to consider is to use a SFSB that writes on the file system. If you implement SessionSynchronization interface, you get beforeCompletion and afterCompletion callbacks. The later indicates whether the transaction was committed or rolled back and you do cleanup if necessary. You can then implement a transactional behavior.