Does Castor JDO comply with the SUN JSR-000012 specification?
No, Castor JDO doesn’t comply with the SUN’s JDO specification. Although Castor JDO carries very similar goals as SUN’s JDO, it has been developed independently from the JSR. Although it is not impossible to shape (perhaps “hammer” is a more descriptive verb) Castor JDO into the SUN’s JDO specification, there are several major technical differences which make it unfavorable to do so. Castor is RDBMS centric. Each persistence object loaded by Castor is locked. Locks in Castor are observable, meaning that locks may not be granted because of timeout or deadlock. On the other hand, the SUN’s JDO hides details about locks. Internally, Castor JDO maintains a single copy of lock (and cache) for each active persistence object for all transaction. SUN’s JDO specification implicitly requires a copy of cache per object per transaction. SUN’s JDO also implicitly requires a bytecode modifier which Castor doesn’t require. Castor also provides other features, such as key generators, long transaction
No, Castor JDO doesn’t comply with the SUN’s JDO specification.Although Castor JDO carries very similar goals as SUN’s JDO, it has been developed independently from the JSR.Although it is not impossible to shape (perhaps “hammer” is a more descriptive verb) Castor JDO into the SUN’s JDO specification, there are several major technical differences which make it unfavorable to do so. Castor is RDBMS centric. Each persistence object loaded by Castor is locked. Locks in Castor are observable, meaning that locks may not be granted because of timeout or deadlock. On the other hand, the SUN’s JDO hides details about locks.Internally, Castor JDO maintains a single copy of lock (and cache) for each active persistence object for all transaction. SUN’s JDO specification implicitly requires a copy of cache per object per transaction. SUN’s JDO also implicitly require a bytecode modifier which Castor doesn’t require.
