I am working on a project where a Java servlet front-end handling 
UI interactions will work with a back-end engine (the one that implements 
the "business logic") which in turn will use an underlying, transaction-capable 
data store, probably an Oracle database.
The engine will abstract the functionality to the point where the client 
servlet won't, and must not, know that Oracle is underneath. 
As such, it will actually wrap tables into specialized objects that load 
information from Oracle using SQL queries, and store information back into Oracle 
the same way.
Has anybody grappled with the intricacies of such a three-tier architecture? 
The implications for transaction control and cache coherency are interesting and 
potentially huge. 
In effect, our engine becomes a database in itself, as has been pointed out by an 
OODBMS developer that we have spoken with -- and much of the logic we will need to 
implement ends up mimicking or reinventing the functionality of generic O/R mappings 
such as Castor.
I realize that this sounds vague, but anyone who has bumped into the problem before should recognize 
the design issues, hopefully :-) 
In researching the subject, we have looked at OODBMS products like Versant, ObjectStore and Ozone. 
Of these, Ozone was the most convenient since its transaction model interfered minimally with the 
application code, whereas Versant and ObjectStore both require explicit transaction semantics in the 
code (resulting in, imho, a clutter of try-except-finally blocks and needless database code). 
Unfortunatelly, Ozone does not seem mature, and it is based on RMI, which in our opinion would result 
in excessive calls and object references across process boundaries.
We have also looked at Castor, the open-source O/R mapping framework, but Castor does not work well in load-balanced clusters, because Castor instances cannot communicate 
with other instances -- this becomes a problem with record locking.
In short, we should *like* to use an O/R mapping or OODBMS, but so far the products evaluated have not matched our expectations.