{quote:jpmsi}
I imagine the case of a relational database that has jobs that run every night (just an example) or an older tool still in use, that has access to the database. You may wish for, but can never assume that yours will be the only application using the database.
{quote}

Well, yes you're right... but what about saying no to that kind of things? Create a hook in the application where you can run scripts (Java, Groovy, or something else) that use application transactions and persistence.\\ 
But this is in a perfect world. Real life legacy code might indeed be a problem, that is, if you cannot have access to change it. If you can change the code I would suggest a refactorization to the previous idea. 

Although if by any horrible crippled need, the database will be directly modified  during application's runtime, my suggestion is to persist the object versions, and each time you try to commit a given object you'll not only check if the version was modified but also if the version in the database is the same in memory. If such change was made, then everytime the object is accessed there's also the need to check if the object's version is up to date with the one in the database and, if not reloading the object. I __strongly__ advice __against__ this kind of behaviour this will give you many headaches.