Hi, sure. Basically, when you start a transaction with Castor JDO using database.begin(), internally a new TransactionContext instance will be created. This is used to track the various user activities of this transaction, e.g. creates, loads, ..... In Hibernate, this information pockets associated with the TransactionContext are called '1st level cache'.
Once a commit is issued, the information maintained within this TransactionContext is used to prepare the various SQL statements required to update the data in the persistence store, i.e. for example store the new created objects in the persistence store. Using the mapping file, the user can configure 2nd level caches for each mapped domain object, with varying configuration options. When used, Castor JDO internally will use those caches when e.g. loading objects from the persistence store. This way, once an object has been loaded into a cache, no SQL statements will be issued anymore against the persistence store. And now the last one: for detachment (JPA term) you need to associate timestamp information with the objects being detached. In other words, if you detach a domain object from the currently running transaction, Castor will load it from the persistence store and attach the timestamp of the load operation to it. At the same time, the detached object is put into the 2nd level cache. Upon re-attaching the detached obejct, amongst other things, the timestamps are being compared to see whether the object has been updated during the detachment period. In other words, you need a cache for detachment to work. Internally, Castor JDO uses the 2nd level cache for this, which in my opinion is not ideal and should be refactored. Does this address all we talked about ? Werner Lukas Lang wrote: > Hello Werner, > > I know, we discussed that last week in personal, but > could you please again explain the different cache levels (1st, 2nd, > update cache) of Castor to me? > > I'm writing to the dev list, because this might be interesting for > others too. > > Thanks, > Lukas > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
