Transactions (Atomicity property) in EJB 3 apply only to Database Operations - Am I right?

Question

I know that transactions could be used to bring about atomicity.

Like if methodOne() methodTwo() methodThree() are clubbed into one transaction, if any of the method fails, the entire operation is rolled back. A rollback would result in a database-level rollback and as a result the database would be brought to a state, as it was before the transaction.

But what if the methods made changes to state-variables or static-variables or wrote to some files in the filesystem ? My understanding is that a "rollback" doesn't apply for such non-database modifications and that those changes are not undone. Is my understanding right ?

Answer 1

File system resources are not transactional. So you would have to roll your changes back. Or you would have to look at file system resource adapters provided by containers.

Answer 2

Transactions in that context refer to Database Transactions. If you place Java code, which alter variables, or produce output to filesystem, you're not using it well. You should start a transaction and make operations just to the Database.

Although, if your DBMS make changes to your filesystem (through a Store Procedure, for example), then you must check the documentation of that DBMS.

So, read your code, if you have code after the "START TRANSACTION" command, you must review it.

Answer 3

Transactions (Atomicity property) in EJB 3 apply only to Database Operations - Am I right?

No you're not. Transactions apply to transactional resources, the Java EE specification recognizing three types of transactional resources: JDBC databases, JMS destinations, and "other transactional services accessed through JCA".

But what if the methods made changes to state-variables or static-variables or wrote to some files in the filesystem?

Those are not transactional resources (unless you're writing to the file system through a JCA connector for the later).