[castor-dev] CPA Cache Levels

Discussion:

Lukas Lang

2009-07-08 10:22:44 UTC

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

Werner Guttmann

2009-07-09 08:06:06 UTC

Permalink

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

Post by Lukas Lang
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
---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Ralf Joachim

2009-07-09 08:25:40 UTC

Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Lukas, Werner, 
 
see my comment inline. 
 
Werner Guttmann schrieb:
<blockquote cite="mid:***@gmx.net" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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. 
<blockquote cite="mid:***@gmx.net" type="cite">
<pre wrap="">
Does this address all we talked about ?

Werner

Lukas Lang wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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:

<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>

</pre>
</blockquote>
<pre wrap="">
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>

</pre>
</blockquote>
 
<pre class="moz-signature" cols="72">--

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: <a class="moz-txt-link-abbreviated" href="http://www.syscon.eu">www.syscon.eu</a>
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:***@syscon.eu">***@syscon.eu</a>

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
</pre>
</body>
</html>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Werner Guttmann

2009-07-09 08:56:22 UTC

Permalink

Great. I thought this still was progress in work. Where in the JDO
documentation can I (we) find information about this ?

Werner

Post by Ralf Joachim
Hi Lukas, Werner,
see my comment inline.

Post by Werner Guttmann
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.

Post by Werner Guttmann
Does this address all we talked about ?
Werner

---------------------------------------------------------------------
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
Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
--------------------------------------------------------------------- To
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Ralf Joachim

2009-07-09 14:55:52 UTC

Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Only in release notes of 1.3rc1. 
 
Werner Guttmann schrieb:
<blockquote cite="mid:***@gmx.net" type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Lukas, Werner,

see my comment inline.

Werner Guttmann schrieb:
</pre>
<blockquote type="cite">
<pre wrap="">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.

</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">Does this address all we talked about ?

Werner

Lukas Lang wrote:

</pre>
<blockquote type="cite">
<pre wrap="">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:

<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>

</pre>
</blockquote>
<pre wrap="">---------------------------------------------------------------------
To unsubscribe from this list, please visit:

<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>

</pre>
</blockquote>
<pre wrap="">--

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: <a class="moz-txt-link-abbreviated" href="http://www.syscon.eu">www.syscon.eu</a>
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:***@syscon.eu">***@syscon.eu</a>

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim

--------------------------------------------------------------------- To
unsubscribe from this list, please visit:
<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>
</pre>
</blockquote>
<pre wrap="">
---------------------------------------------------------------------
To unsubscribe from this list, please visit:

<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>

</pre>
</blockquote>
 
<pre class="moz-signature" cols="72">--

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: <a class="moz-txt-link-abbreviated" href="http://www.syscon.eu">www.syscon.eu</a>
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:***@syscon.eu">***@syscon.eu</a>

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
</pre>
</body>
</html>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Werner Guttmann

2009-07-09 18:43:18 UTC

Permalink

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

Post by Ralf Joachim
Only in release notes of 1.3rc1.

Post by Werner Guttmann
Great. I thought this still was progress in work. Where in the JDO
documentation can I (we) find information about this ?
Werner

Post by Ralf Joachim
Hi Lukas, Werner,
see my comment inline.

Post by Werner Guttmann
Does this address all we talked about ?
Werner

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Lukas Lang

2009-07-10 08:59:44 UTC

Permalink

Hey,

I updated the guide and added a section on long transactions.

Lukas

Post by Werner Guttmann
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

Post by Ralf Joachim
Only in release notes of 1.3rc1.

Post by Werner Guttmann
Great. I thought this still was progress in work. Where in the JDO
documentation can I (we) find information about this ?
Werner

Post by Ralf Joachim
Hi Lukas, Werner,
see my comment inline.

Post by Werner Guttmann
Does this address all we talked about ?
Werner

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Werner Guttmann

2009-07-10 12:31:37 UTC

Permalink

Thanks, Lukas.

Werner

Post by Lukas Lang
Hey,
I updated the guide and added a section on long transactions.
Lukas

Post by Ralf Joachim
Only in release notes of 1.3rc1.

Post by Werner Guttmann
Great. I thought this still was progress in work. Where in the JDO
documentation can I (we) find information about this ?
Werner

Post by Ralf Joachim
Hi Lukas, Werner,
see my comment inline.

Post by Werner Guttmann
Does this address all we talked about ?
Werner

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Werner Guttmann

2009-07-10 12:32:49 UTC

Permalink

Hi,

I was originally thinking about amending the existing JDO HTML docs so
that everything is in one place.

Regards
Werner

Post by Lukas Lang
Hey,
I updated the guide and added a section on long transactions.
Lukas

Post by Ralf Joachim
Only in release notes of 1.3rc1.

Post by Werner Guttmann
Great. I thought this still was progress in work. Where in the JDO
documentation can I (we) find information about this ?
Werner

Post by Ralf Joachim
Hi Lukas, Werner,
see my comment inline.

Post by Werner Guttmann
Does this address all we talked about ?
Werner

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Lukas Lang

2009-07-09 10:18:54 UTC

Permalink

Hey,

Post by Ralf Joachim

Post by Werner Guttmann
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.

I assume, Timestampable interface must be implemented anyway, right?

Lukas

Post by Ralf Joachim

Post by Werner Guttmann
Does this address all we talked about ?
Werner

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Ralf Joachim

2009-07-09 14:57:11 UTC

Permalink

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Lukas, 
 
you are right, Timestample interface have to be implemented. 
 
Regards 
Ralf 
 
Lukas Lang schrieb:
<blockquote cite="mid:***@inode.at" type="cite">
<pre wrap="">Hey,

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.

</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">

I assume, Timestampable interface must be implemented anyway, right?

Lukas

</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Does this address all we talked about ?

Werner

Lukas Lang wrote:

</pre>
<blockquote type="cite">
<pre wrap="">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:

<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>

</pre>
</blockquote>
<pre wrap="">---------------------------------------------------------------------
To unsubscribe from this list, please visit:

<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>

</pre>
</blockquote>
<pre wrap="">--

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: <a class="moz-txt-link-abbreviated" href="http://www.syscon.eu">www.syscon.eu</a>
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:***@syscon.eu">***@syscon.eu</a>

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim

--------------------------------------------------------------------- To
unsubscribe from this list, please visit:
<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>
</pre>
</blockquote>
<pre wrap="">

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

<a class="moz-txt-link-freetext" href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>

</pre>
</blockquote>
 
<pre class="moz-signature" cols="72">--

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: <a class="moz-txt-link-abbreviated" href="http://www.syscon.eu">www.syscon.eu</a>
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:***@syscon.eu">***@syscon.eu</a>

Sitz der Gesellschaft: D-72127 Kusterdingen
Registereintrag: Amtsgericht Stuttgart, HRB 382295
Geschäftsleitung: Jens Joachim, Ralf Joachim
</pre>
</body>
</html>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

Lukas Lang

2009-07-09 10:15:27 UTC

Permalink

Thanks for the detailed explanation!

Lukas

---------------------------------------------------------------------
http://xircles.codehaus.org/manage_email

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email