Re: Data + Query cache
Is there a way to query OpenJPA if the result came from the cache? Or are partial cache results possible, thus making such a isCached() method impossible to implement. -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 25.08.2006 um 14:39 schrieb Kevin Sutter: Abe, In general, I wouldn't mind having the level 2 caches turned on by default. My concern is that we don't want first time users to get unexpected results. Like you mentioned in your previous reply, if we select the appropriate default values for the caches so that we can most likely avoid stale reads, but still help with general performance, then I'm okay with the idea. But, if these caches cause our users to question the results or require them to tweak the cache settings for their first applications, then I would prefer to go the safe route and leave the caches turned off by default. All that I know about these caches at this point is what you have documented in your OpenJPA manual, so I don't have much personal experience with them. The goal should be to have a pleasant first-time experience with OpenJPA. :-) Kevin On 8/24/06, Abe White [EMAIL PROTECTED] wrote: t I was looking for some documentation about what the default cache configuration settings would be, and I'm not seeing it there. The defaults are: - Data cache maintains hard refs to 1000 PCData object, where a PCData holds the cached data for a single persistence-capable object. - When the 1000 object limit is exceeded, we move random objects to a soft backing map. This map does not have a size limit, other than what the JVM decides to GC. The reason we evict randomly is that LRU eviction requires more synchronization. - Query cache has the same defaults (1000 hard refs, soft backing map), but each entry is a list of oids for matching objects, or object/object[] in the case of projections. All this is user-configurable, of course. 1) How much memory would the default 'cache on' setting consume? Are people going to easily receive OOM errors with the default settings? (I doubt it, but thought it should be mentioned.) The above defaults shouldn't cause OOM errors in most JVMs. 2) What's the default concurrency strategy? My wife and I making an ATM withdrawal or deposit at the same time makes me nervous the farther away from transactional we get. We bypass the cache during non-optimistic transactions, so DB locking isn't affected. And the standard optimistic checks ensure data integrity in non-optimistic transactions. If you start using the cache in a distributed environment or among multiple EntityManagerFactories you have to consider possible stale reads if the cache invalidation notification from one EMF hasn't reached the others yet, but that's not the common case. _ __ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Data + Query cache
(Performance pack is Kodo parlance, and this is a Kodo-related email.) Actually, we're getting rid of Performance Pack altogether, at long last, and replacing with a Professional Edition. (I never much liked the Performance Pack name, given that the other two were editions.) I don't remember the details of what lands where, but we aren't going to be selling things that are available in OpenJPA. You can get a feeling for what the JDO bindings for Kodo look like by taking a look at the openjpa-persistence and openjpa-persistence-jdbc modules in OpenJPA -- you'll notice that the bindings largely add spec behavior to the core kernel. So the features available in the core kernel are available to all bindings. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 7:01 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, does that mean that the performance pack gets obsolete or how do you want to control the cache then? It would be weird to sell the cache to JDO users while its free for JPA users right? -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 24.08.2006 um 22:54 schrieb Abe White: How does the list feel about turning the L2 data and query caches on by default? Traditionally, Kodo always left them off by default, primarily because they required a performance pack license to run. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. smime.p7s Description: S/MIME cryptographic signature
Re: Data + Query cache
Hi, of course my intention wasnt to ask about kodo, but i was confused that a feature will be on by default that was formerly on sale. I will look into the packages to get an idea. The other question regarding the cache or a method like isCached() was to solve the issue that users could get irritated where the results come from. Without such a method, there is no way to solve the irritation for certain users then ;-) But the other thing is, if you dont turn it on by default, you can be sure to see a review that says that hibernate is faster by default on some JavaEE portal. -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 25.08.2006 um 18:31 schrieb Patrick Linskey: (Performance pack is Kodo parlance, and this is a Kodo-related email.) Actually, we're getting rid of Performance Pack altogether, at long last, and replacing with a Professional Edition. (I never much liked the Performance Pack name, given that the other two were editions.) I don't remember the details of what lands where, but we aren't going to be selling things that are available in OpenJPA. You can get a feeling for what the JDO bindings for Kodo look like by taking a look at the openjpa-persistence and openjpa-persistence-jdbc modules in OpenJPA -- you'll notice that the bindings largely add spec behavior to the core kernel. So the features available in the core kernel are available to all bindings. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 7:01 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, does that mean that the performance pack gets obsolete or how do you want to control the cache then? It would be weird to sell the cache to JDO users while its free for JPA users right? -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 24.08.2006 um 22:54 schrieb Abe White: How does the list feel about turning the L2 data and query caches on by default? Traditionally, Kodo always left them off by default, primarily because they required a performance pack license to run. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Data + Query cache
DataCache or L2 cache being a performance optimization feature not mandated by the spec, makes it a candidate for *not* being on by default. a) If the user explictly turns the feature on, it makes him/her aware of its advantages as well as behavioral difference e.g. refresh(). b) If the user turns it on and observes a performance improvement -- that makes the benefit of the feature obvious. c) It keeps the option of product level differentiation open On the other hand, if the feature is on by default what would be the likely reason to turn it off? Some JavaEE portal may then report how default behaviour of OpenJPA is not spec-compliant :( On performance front, initial results indicate that OpenJPA is significantly better than other alternatives against industry standard benchmarks -- so even leaving DataCache off would not give a reason to report otherwise. Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 10:18 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, of course my intention wasnt to ask about kodo, but i was confused that a feature will be on by default that was formerly on sale. I will look into the packages to get an idea. The other question regarding the cache or a method like isCached() was to solve the issue that users could get irritated where the results come from. Without such a method, there is no way to solve the irritation for certain users then ;-) But the other thing is, if you dont turn it on by default, you can be sure to see a review that says that hibernate is faster by default on some JavaEE portal. -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 25.08.2006 um 18:31 schrieb Patrick Linskey: (Performance pack is Kodo parlance, and this is a Kodo-related email.) Actually, we're getting rid of Performance Pack altogether, at long last, and replacing with a Professional Edition. (I never much liked the Performance Pack name, given that the other two were editions.) I don't remember the details of what lands where, but we aren't going to be selling things that are available in OpenJPA. You can get a feeling for what the JDO bindings for Kodo look like by taking a look at the openjpa-persistence and openjpa-persistence-jdbc modules in OpenJPA -- you'll notice that the bindings largely add spec behavior to the core kernel. So the features available in the core kernel are available to all bindings. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 7:01 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, does that mean that the performance pack gets obsolete or how do you want to control the cache then? It would be weird to sell the cache to JDO users while its free for JPA users right? -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 24.08.2006 um 22:54 schrieb Abe White: How does the list feel about turning the L2 data and query caches on by default? Traditionally, Kodo always left them off by default, primarily because they required a performance pack license to run. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
Re: Data + Query cache
inline... Pinaki Poddar wrote: DataCache or L2 cache being a performance optimization feature not mandated by the spec, makes it a candidate for *not* being on by default. a) If the user explictly turns the feature on, it makes him/her aware of its advantages as well as behavioral difference e.g. refresh(). b) If the user turns it on and observes a performance improvement -- that makes the benefit of the feature obvious. c) It keeps the option of product level differentiation open On the other hand, if the feature is on by default what would be the likely reason to turn it off? Some JavaEE portal may then report how default behaviour of OpenJPA is not spec-compliant :( On performance front, initial results indicate that OpenJPA is significantly better than other alternatives against industry standard benchmarks -- so even leaving DataCache off would not give a reason to report otherwise. Wow... cool. Do you have or are you planning to make these 'initial results' available publicly? It would be handy for people to have that kind of information in their back pocket if they need it. Thanks... Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 10:18 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, of course my intention wasnt to ask about kodo, but i was confused that a feature will be on by default that was formerly on sale. I will look into the packages to get an idea. The other question regarding the cache or a method like isCached() was to solve the issue that users could get irritated where the results come from. Without such a method, there is no way to solve the irritation for certain users then ;-) But the other thing is, if you dont turn it on by default, you can be sure to see a review that says that hibernate is faster by default on some JavaEE portal. -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 25.08.2006 um 18:31 schrieb Patrick Linskey: (Performance pack is Kodo parlance, and this is a Kodo-related email.) Actually, we're getting rid of Performance Pack altogether, at long last, and replacing with a Professional Edition. (I never much liked the Performance Pack name, given that the other two were editions.) I don't remember the details of what lands where, but we aren't going to be selling things that are available in OpenJPA. You can get a feeling for what the JDO bindings for Kodo look like by taking a look at the openjpa-persistence and openjpa-persistence-jdbc modules in OpenJPA -- you'll notice that the bindings largely add spec behavior to the core kernel. So the features available in the core kernel are available to all bindings. -Patrick -- Patrick Linskey BEA Systems, Inc. -Original Message- From: Marc Logemann [mailto:[EMAIL PROTECTED] Sent: Friday, August 25, 2006 7:01 AM To: open-jpa-dev@incubator.apache.org Subject: Re: Data + Query cache Hi, does that mean that the performance pack gets obsolete or how do you want to control the cache then? It would be weird to sell the cache to JDO users while its free for JPA users right? -- regards Marc Logemann [blog] http://www.logemann.org [busn] http://www.logentis.de Am 24.08.2006 um 22:54 schrieb Abe White: How does the list feel about turning the L2 data and query caches on by default? Traditionally, Kodo always left them off by default, primarily because they required a performance pack license to run. __ _ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Data + Query cache
On the other hand, if the feature is on by default what would be the likely reason to turn it off? Some JavaEE portal may then report how default behaviour of OpenJPA is not spec-compliant :( How is the data cache not spec-compliant? -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. smime.p7s Description: S/MIME cryptographic signature
RE: Data + Query cache
I did not mean it is. I was just how a some JavaEE portal may spin it! Pinaki Poddar BEA Systems 415.402.7317 -Original Message- From: Patrick Linskey Sent: Friday, August 25, 2006 11:22 AM To: open-jpa-dev@incubator.apache.org Subject: RE: Data + Query cache On the other hand, if the feature is on by default what would be the likely reason to turn it off? Some JavaEE portal may then report how default behaviour of OpenJPA is not spec-compliant :( How is the data cache not spec-compliant? -Patrick ___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
RE: Data + Query cache
I think the first time users are going to write simple applications while evaluating . Will caching affect these kind of applications which have a small amount of data to play around with? Typically, no. -Patrick___ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. smime.p7s Description: S/MIME cryptographic signature
