I'm investigating migrating portions of an internal framework to Castor
JDO, and I want a way to make in-memory objects that take advantage of the
same locks and rollback/commit functionality as the persistent objects.
Implementing my own Persistence class (and PersistenceFactory) doesn't
seem to be too hard (as long as I don't need query support), however the
current Castor JDO only has a single PersistenceManager per Database.
Since the DatabaseImpl wraps the underlying Transaction object in a Castor
TransactionContext, this mean that objects living in different databases
won't do deadlock detection correctly.
As a workaround I plan to construct a proxy PersistenceFactory that
delegates to one of the existing SQL based factories except for the
classes which will use my in-memory Persistence implementation. (A more
general composite proxy is not possible because the ClassDescriptor is not
available to getQueryExpression or quoteName.)
1. Is the idea of an in-memory Persistence implementation feasible?
2. Are there any plans to allow the PersistenceFactory to be specified in
a more flexible manner?
3. Besides deadlock detection problems, are there other hinderances to
using multiple Database-s in a single transaction? If this is the only
problem, it seems feasible to store the information required for deadlock
detection in a global context indexed by the transaction name (or perhaps
a ThreadLocal).
4. I'm new to Castor, so if I am confused about how things work please
tell me. I have been working with Castor 0.9.3.9.
Thanks,
Nathan
----------------------------------------------------
Nathan Bronson [EMAIL PROTECTED]
"Once you get above 100 feet, it doesn't matter"
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
