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.