Great. I thought this still was progress in work. Where in the JDO documentation can I (we) find information about this ?
Werner Ralf Joachim wrote: > Hi Lukas, Werner, > > see my comment inline. > > Werner Guttmann schrieb: >> 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. >> > Since 1.3 it is possible to persist the timestamp of an object which > allows to work with detached objects without any cache. In other words, > if you persist timestamps detachment works without cache, if timestamp > is not persisted object has to stay in 2nd level cache between detaching > and reataching it. >> 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 >> >> >> > > -- > > Syscon Ingenieurbüro für Meß- und Datentechnik GmbH > Ralf Joachim > Raiffeisenstraße 11 > 72127 Kusterdingen > Germany > > Tel. +49 7071 3690 52 > Mobil: +49 173 9630135 > Fax +49 7071 3690 98 > > Internet: www.syscon.eu > E-Mail: ralf.joac...@syscon.eu > > Sitz der Gesellschaft: D-72127 Kusterdingen > Registereintrag: Amtsgericht Stuttgart, HRB 382295 > Geschäftsleitung: Jens Joachim, Ralf Joachim > > --------------------------------------------------------------------- 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
