Hi, I was originally thinking about amending the existing JDO HTML docs so that everything is in one place.
Regards Werner Lukas Lang wrote: > Hey, > > I updated the guide and added a section on long transactions. > > Lukas > > Werner Guttmann schrieb: >> Thanks, Ralf. I actually didn't think of looking there. >> >> Anyhow, Lukas, can you please try to copy the relevant bits and pieces >> to the HTML docs, and to describe the available mechanism in this area >> from a user's point of view. >> >> This would be very nice, indeed. >> >> Werner >> >> Ralf Joachim wrote: >>> Only in release notes of 1.3rc1. >>> >>> Werner Guttmann schrieb: >>>> 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 >>>> >>>> >>>> >>> -- >>> >>> 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 >> >> >> > > > --------------------------------------------------------------------- > 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
