I want to do following operation:

When DCP is published, DCP is stored to Broker DB, and also stored to my custom DB by Storage Extension.

I found it's possible by extending JPAComponentPresentationDAO class and implementing ComponentPresentationDAO interface, and call super.create() in its create() method, and write some custom program in Java code.

But problem is, it needs to excute both storing to Broker DB and to my custom DB in same transaction. It means that if some exception occurs in Storage Extension, storing DCP to Broker DB have to be rollbacked too.

How is it possible to excute storing to Broker DB and custom DB in same transaction, when existing itemtype(ComponentPresentaion) is used?

3 Answers 3


The point at which the storage of the item is committed is not at individual item level, but at DAOFactory level (JPADAOFactory or FSDAOFactory for DB/Filesystem). The reason for this is typically the publish transaction will store several items (page, metadata, binaries etc.) and the commit of the storage should be all items together. So in order to hook in to the moment a transaction is committed, you need to extend the appropriate DAOFactory and look into the commitTransaction method.

This is relatively straightforward for FSDAOFactory (see my example on CDN integration) however there are some issues with JPADAOFactory which require some work arounds. It is possible, however - for an example check out the SI4T JPASearchDAOFactory class.

I am not sure if its possible to manage the 2 transactions as one in your DAOFactory, but if you decompile the CD jar files it will give you a better idea of how transactions are managed (probably something with Hibernate).

There is a deployment phase called Prepare Commit which is likely to catch any issues with committing the transaction, so if you get to the point where DAOFactory.commitTransaction is called, you can be reasonably confident that the transaction in the broker db will succeed. In which case in your MyJPADAOFactory commitTransaction method could first try to commit the transaction in your custom db, and if that succeeds call super.commitTransaction to commit in the broker DB, if it fails, throw an error and the transaction will not be committed in the broker DB.

  • I didn't metion clearly, but my custom DB is another DB from Broker DB. Broker DB is SQL Server, and my custom DB is for instace postgre. In this situation, is it possible to execute those 2 programs in same transaction? And is Tridion CD using Java's JTA? Commented Jul 31, 2013 at 8:36
  • I added a bit more to my answer to address committing both transactions together.
    – Will Price
    Commented Jul 31, 2013 at 10:14

Unfortunately it is not possible to use a custom com.tridion.storage.persistence.JPADAOFactoryby design, this type is statically used by the storage layer and it will ignore a custom one avoiding adding new operations to the transaction.


I might be missing something here, but isn't this just as simple as calling super.create() after you have executed your code successfully?

It is somewhat common practice to call the superclass first, but depending on circumstances, it may be appropriate to:

  • call super last
  • handle some cases yourself, call super for the rest
  • never call super

So if your code should fail, make sure that error is not caught, or at least rethrown, so that the superclass call is never reached.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.