Entity Caching
Locked
123
123
 
|
I would like to share some insights into the entity cache feature, some
best practices I like to follow, and some related information. Some OFBiz experts may disagree with some of my views, and that is okay. Different experiences with OFBiz will lead to different viewpoints. The OFBiz entity caching feature is intended to improve performance by keeping GenericValue instances in memory - decreasing the number of calls to the database. Background ---------- Initially, the entity cache was very unreliable due to a number of flaws in its design and in the code that calls it (it was guaranteed to produce stale data). As a result, I personally avoided using the entity cache feature. Some time ago, Adam Heath did a lot of work on the entity cache. After that, Jacopo and I did a lot of work fixing stale data issues in the entity cache. Today, the entity cache is much improved and unit tests ensure it produces the correct data (except for one edge case that Jacopo has identified). I mention all of this because the previous quirky behavior led to some "best practices" that didn't make much sense. A search through the OFBiz mail archives will produce a mountain of conflicting and confusing information. Today ----- Since the current entity cache is reliable, there is no reason NOT to use it. My preference is to make ALL Delegator calls use the cache. If all code uses the cache, then individual entities can have their caching characteristics configured outside of code. This enables sysadmins to fine-tune entity caches for best performance. [Some experts might disagree with this approach because the entity cache will consume all available memory. But the idea is to configure the cache so that doesn't happen.] If you code Delegator calls to avoid the cache, then there is no way for a sysadmin to configure the caching behavior - that bit of code will ALWAYS make a database call. If you make all Delegator calls use the cache, then there is an additional complication that will add a bit more code: the GenericValue instances retrieved from the cache are immutable - if you want to modify them, then you will have to clone them. So, this approach can produce an additional line of code. -- Adrian Crum Sandglass Software www.sandglass-software.com |
|
|
Hi Adrian,
How would this work in a clustered or load balanced environment? With multiple nodes always checking their own local caches incorrect data would be persisted all the time. Regards, Rupert On 18 March 2015 at 12:16, Adrian Crum <[hidden email]> wrote: > I would like to share some insights into the entity cache feature, some > best practices I like to follow, and some related information. > > Some OFBiz experts may disagree with some of my views, and that is okay. > Different experiences with OFBiz will lead to different viewpoints. > > The OFBiz entity caching feature is intended to improve performance by > keeping GenericValue instances in memory - decreasing the number of calls > to the database. > > Background > ---------- > > Initially, the entity cache was very unreliable due to a number of flaws > in its design and in the code that calls it (it was guaranteed to produce > stale data). As a result, I personally avoided using the entity cache > feature. > > Some time ago, Adam Heath did a lot of work on the entity cache. After > that, Jacopo and I did a lot of work fixing stale data issues in the entity > cache. Today, the entity cache is much improved and unit tests ensure it > produces the correct data (except for one edge case that Jacopo has > identified). > > I mention all of this because the previous quirky behavior led to some > "best practices" that didn't make much sense. A search through the OFBiz > mail archives will produce a mountain of conflicting and confusing > information. > > Today > ----- > > Since the current entity cache is reliable, there is no reason NOT to use > it. My preference is to make ALL Delegator calls use the cache. If all code > uses the cache, then individual entities can have their caching > characteristics configured outside of code. This enables sysadmins to > fine-tune entity caches for best performance. > > [Some experts might disagree with this approach because the entity cache > will consume all available memory. But the idea is to configure the cache > so that doesn't happen.] > > If you code Delegator calls to avoid the cache, then there is no way for a > sysadmin to configure the caching behavior - that bit of code will ALWAYS > make a database call. > > If you make all Delegator calls use the cache, then there is an additional > complication that will add a bit more code: the GenericValue instances > retrieved from the cache are immutable - if you want to modify them, then > you will have to clone them. So, this approach can produce an additional > line of code. > > > -- > Adrian Crum > Sandglass Software > www.sandglass-software.com > -- Rupert Howell Provolve Ltd Front Office, Deale House, 16 Lavant Street, Petersfield, GU32 3EW, UK t: 01730 267868 / m: 079 0968 5308 e: [hidden email] w: http://www.provolve.com |
|
|
A clustered environment must use distributed cache clearing.
Adrian Crum Sandglass Software www.sandglass-software.com On 3/18/2015 12:34 PM, Rupert Howell wrote: > Hi Adrian, > > How would this work in a clustered or load balanced environment? With > multiple nodes always checking their own local caches incorrect data would > be persisted all the time. > > Regards, > > Rupert > > On 18 March 2015 at 12:16, Adrian Crum <[hidden email]> > wrote: > >> I would like to share some insights into the entity cache feature, some >> best practices I like to follow, and some related information. >> >> Some OFBiz experts may disagree with some of my views, and that is okay. >> Different experiences with OFBiz will lead to different viewpoints. >> >> The OFBiz entity caching feature is intended to improve performance by >> keeping GenericValue instances in memory - decreasing the number of calls >> to the database. >> >> Background >> ---------- >> >> Initially, the entity cache was very unreliable due to a number of flaws >> in its design and in the code that calls it (it was guaranteed to produce >> stale data). As a result, I personally avoided using the entity cache >> feature. >> >> Some time ago, Adam Heath did a lot of work on the entity cache. After >> that, Jacopo and I did a lot of work fixing stale data issues in the entity >> cache. Today, the entity cache is much improved and unit tests ensure it >> produces the correct data (except for one edge case that Jacopo has >> identified). >> >> I mention all of this because the previous quirky behavior led to some >> "best practices" that didn't make much sense. A search through the OFBiz >> mail archives will produce a mountain of conflicting and confusing >> information. >> >> Today >> ----- >> >> Since the current entity cache is reliable, there is no reason NOT to use >> it. My preference is to make ALL Delegator calls use the cache. If all code >> uses the cache, then individual entities can have their caching >> characteristics configured outside of code. This enables sysadmins to >> fine-tune entity caches for best performance. >> >> [Some experts might disagree with this approach because the entity cache >> will consume all available memory. But the idea is to configure the cache >> so that doesn't happen.] >> >> If you code Delegator calls to avoid the cache, then there is no way for a >> sysadmin to configure the caching behavior - that bit of code will ALWAYS >> make a database call. >> >> If you make all Delegator calls use the cache, then there is an additional >> complication that will add a bit more code: the GenericValue instances >> retrieved from the cache are immutable - if you want to modify them, then >> you will have to clone them. So, this approach can produce an additional >> line of code. >> >> >> -- >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> > > > |
|
|
Yes I'm aware of this. If everything was cached Surely every persist would
need to trigger a JMS message telling all the other servers to dump their local cache. This overhead would be big, the amount of messages flying out would be hugely increased and the caches would be redundant anyway because they'd be constantly being dumped. It doesn't seem scalable. On 18 March 2015 at 12:49, Adrian Crum <[hidden email]> wrote: > A clustered environment must use distributed cache clearing. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 3/18/2015 12:34 PM, Rupert Howell wrote: > >> Hi Adrian, >> >> How would this work in a clustered or load balanced environment? With >> multiple nodes always checking their own local caches incorrect data would >> be persisted all the time. >> >> Regards, >> >> Rupert >> >> On 18 March 2015 at 12:16, Adrian Crum <adrian.crum@sandglass- >> software.com> >> wrote: >> >> I would like to share some insights into the entity cache feature, some >>> best practices I like to follow, and some related information. >>> >>> Some OFBiz experts may disagree with some of my views, and that is okay. >>> Different experiences with OFBiz will lead to different viewpoints. >>> >>> The OFBiz entity caching feature is intended to improve performance by >>> keeping GenericValue instances in memory - decreasing the number of calls >>> to the database. >>> >>> Background >>> ---------- >>> >>> Initially, the entity cache was very unreliable due to a number of flaws >>> in its design and in the code that calls it (it was guaranteed to produce >>> stale data). As a result, I personally avoided using the entity cache >>> feature. >>> >>> Some time ago, Adam Heath did a lot of work on the entity cache. After >>> that, Jacopo and I did a lot of work fixing stale data issues in the >>> entity >>> cache. Today, the entity cache is much improved and unit tests ensure it >>> produces the correct data (except for one edge case that Jacopo has >>> identified). >>> >>> I mention all of this because the previous quirky behavior led to some >>> "best practices" that didn't make much sense. A search through the OFBiz >>> mail archives will produce a mountain of conflicting and confusing >>> information. >>> >>> Today >>> ----- >>> >>> Since the current entity cache is reliable, there is no reason NOT to use >>> it. My preference is to make ALL Delegator calls use the cache. If all >>> code >>> uses the cache, then individual entities can have their caching >>> characteristics configured outside of code. This enables sysadmins to >>> fine-tune entity caches for best performance. >>> >>> [Some experts might disagree with this approach because the entity cache >>> will consume all available memory. But the idea is to configure the cache >>> so that doesn't happen.] >>> >>> If you code Delegator calls to avoid the cache, then there is no way for >>> a >>> sysadmin to configure the caching behavior - that bit of code will ALWAYS >>> make a database call. >>> >>> If you make all Delegator calls use the cache, then there is an >>> additional >>> complication that will add a bit more code: the GenericValue instances >>> retrieved from the cache are immutable - if you want to modify them, then >>> you will have to clone them. So, this approach can produce an additional >>> line of code. >>> >>> >>> -- >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> >> >> >> -- Rupert Howell Provolve Ltd Front Office, Deale House, 16 Lavant Street, Petersfield, GU32 3EW, UK t: 01730 267868 / m: 079 0968 5308 e: [hidden email] w: http://www.provolve.com |
|
|
In reply to this post by Adrian Crum-3
On Mar 18, 2015, at 1:16 PM, Adrian Crum <[hidden email]> wrote:
> If you code Delegator calls to avoid the cache, then there is no way for a sysadmin to configure the caching behavior - that bit of code will ALWAYS make a database call. > > If you make all Delegator calls use the cache, then there is an additional complication that will add a bit more code: the GenericValue instances retrieved from the cache are immutable - if you want to modify them, then you will have to clone them. So, this approach can produce an additional line of code. There may be situation where it is desirable to use, for the same entity, the cache for some calls and not use the cache for others; removing the ability to set the cache flag from the API would prevent to fine tune some calls. Jacopo |
|
|
In reply to this post by rhowell
I agree there is a lot of overhead with the current distributed cache
clearing implementation. From my perspective, that should be changed to use RMI - where the caches talk directly to each other. Adrian Crum Sandglass Software www.sandglass-software.com On 3/18/2015 1:21 PM, Rupert Howell wrote: > Yes I'm aware of this. If everything was cached Surely every persist would > need to trigger a JMS message telling all the other servers to dump their > local cache. This overhead would be big, the amount of messages flying out > would be hugely increased and the caches would be redundant anyway because > they'd be constantly being dumped. It doesn't seem scalable. > > On 18 March 2015 at 12:49, Adrian Crum <[hidden email]> > wrote: > >> A clustered environment must use distributed cache clearing. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 3/18/2015 12:34 PM, Rupert Howell wrote: >> >>> Hi Adrian, >>> >>> How would this work in a clustered or load balanced environment? With >>> multiple nodes always checking their own local caches incorrect data would >>> be persisted all the time. >>> >>> Regards, >>> >>> Rupert >>> >>> On 18 March 2015 at 12:16, Adrian Crum <adrian.crum@sandglass- >>> software.com> >>> wrote: >>> >>> I would like to share some insights into the entity cache feature, some >>>> best practices I like to follow, and some related information. >>>> >>>> Some OFBiz experts may disagree with some of my views, and that is okay. >>>> Different experiences with OFBiz will lead to different viewpoints. >>>> >>>> The OFBiz entity caching feature is intended to improve performance by >>>> keeping GenericValue instances in memory - decreasing the number of calls >>>> to the database. >>>> >>>> Background >>>> ---------- >>>> >>>> Initially, the entity cache was very unreliable due to a number of flaws >>>> in its design and in the code that calls it (it was guaranteed to produce >>>> stale data). As a result, I personally avoided using the entity cache >>>> feature. >>>> >>>> Some time ago, Adam Heath did a lot of work on the entity cache. After >>>> that, Jacopo and I did a lot of work fixing stale data issues in the >>>> entity >>>> cache. Today, the entity cache is much improved and unit tests ensure it >>>> produces the correct data (except for one edge case that Jacopo has >>>> identified). >>>> >>>> I mention all of this because the previous quirky behavior led to some >>>> "best practices" that didn't make much sense. A search through the OFBiz >>>> mail archives will produce a mountain of conflicting and confusing >>>> information. >>>> >>>> Today >>>> ----- >>>> >>>> Since the current entity cache is reliable, there is no reason NOT to use >>>> it. My preference is to make ALL Delegator calls use the cache. If all >>>> code >>>> uses the cache, then individual entities can have their caching >>>> characteristics configured outside of code. This enables sysadmins to >>>> fine-tune entity caches for best performance. >>>> >>>> [Some experts might disagree with this approach because the entity cache >>>> will consume all available memory. But the idea is to configure the cache >>>> so that doesn't happen.] >>>> >>>> If you code Delegator calls to avoid the cache, then there is no way for >>>> a >>>> sysadmin to configure the caching behavior - that bit of code will ALWAYS >>>> make a database call. >>>> >>>> If you make all Delegator calls use the cache, then there is an >>>> additional >>>> complication that will add a bit more code: the GenericValue instances >>>> retrieved from the cache are immutable - if you want to modify them, then >>>> you will have to clone them. So, this approach can produce an additional >>>> line of code. >>>> >>>> >>>> -- >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> >>> >>> >>> > > |
|
|
In reply to this post by Jacopo Cappellato-5
I would be interested in seeing a use case for that.
I view delegator calls as being no different than SQL statements. Where in the SQL grammar do you tell the database to get a table row from its cache or not? That detail is left to the implementation, and in some cases it can be controlled via database-specific configuration files. Adrian Crum Sandglass Software www.sandglass-software.com On 3/18/2015 1:27 PM, Jacopo Cappellato wrote: > On Mar 18, 2015, at 1:16 PM, Adrian Crum <[hidden email]> wrote: > >> If you code Delegator calls to avoid the cache, then there is no way for a sysadmin to configure the caching behavior - that bit of code will ALWAYS make a database call. >> >> If you make all Delegator calls use the cache, then there is an additional complication that will add a bit more code: the GenericValue instances retrieved from the cache are immutable - if you want to modify them, then you will have to clone them. So, this approach can produce an additional line of code. > > There may be situation where it is desirable to use, for the same entity, the cache for some calls and not use the cache for others; removing the ability to set the cache flag from the API would prevent to fine tune some calls. > > Jacopo > |
|
|
On Mar 18, 2015, at 2:35 PM, Adrian Crum <[hidden email]> wrote:
> I would be interested in seeing a use case for that. This is just an example I could think of (there may be other better examples but I am in a rush and I can't concentrate): Client code A selects a bunch of records from TableFoo in order to update them; cache is disabled to prevent the creation of cache entries that would be expired after a few milliseconds. Client code B selects a bunch of records from TableFoo in order to format a list in a web page; cache is enabled in order to hit the cache after the first visit to the page. Jacopo |
|
|
On 3/18/2015 1:46 PM, Jacopo Cappellato wrote:
> On Mar 18, 2015, at 2:35 PM, Adrian Crum <[hidden email]> wrote: > >> I would be interested in seeing a use case for that. > > This is just an example I could think of (there may be other better examples but I am in a rush and I can't concentrate): > > Client code A selects a bunch of records from TableFoo in order to update them; cache is disabled to prevent the creation of cache entries that would be expired after a few milliseconds. Delegator makes a database call to get the bunch of records. > Client code B selects a bunch of records from TableFoo in order to format a list in a web page; cache is enabled in order to hit the cache after the first visit to the page. Delegator makes a database call to get the bunch of records. If client code A used the cache, then client code B would not have to make a database call (or the reverse). The problem with your use case is, a developer is trying to determine the best caching strategy, and that is not something you can decide at design time. Instead, that is a decision that needs to be made during staging - where you can measure the real-world effects of concurrent processes. Adrian Crum Sandglass Software www.sandglass-software.com |
Administrator
|
In reply to this post by Adrian Crum-3
If a such effort would be undertaken, I'd prefer to go with ehcache: http://ehcache.org/documentation/2.6/get-started/about-distributed-cache
Jacques Le 18/03/2015 14:27, Adrian Crum a écrit : > I agree there is a lot of overhead with the current distributed cache clearing implementation. From my perspective, that should be changed to use > RMI - where the caches talk directly to each other. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 3/18/2015 1:21 PM, Rupert Howell wrote: >> Yes I'm aware of this. If everything was cached Surely every persist would >> need to trigger a JMS message telling all the other servers to dump their >> local cache. This overhead would be big, the amount of messages flying out >> would be hugely increased and the caches would be redundant anyway because >> they'd be constantly being dumped. It doesn't seem scalable. >> >> On 18 March 2015 at 12:49, Adrian Crum <[hidden email]> >> wrote: >> >>> A clustered environment must use distributed cache clearing. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 3/18/2015 12:34 PM, Rupert Howell wrote: >>> >>>> Hi Adrian, >>>> >>>> How would this work in a clustered or load balanced environment? With >>>> multiple nodes always checking their own local caches incorrect data would >>>> be persisted all the time. >>>> >>>> Regards, >>>> >>>> Rupert >>>> >>>> On 18 March 2015 at 12:16, Adrian Crum <adrian.crum@sandglass- >>>> software.com> >>>> wrote: >>>> >>>> I would like to share some insights into the entity cache feature, some >>>>> best practices I like to follow, and some related information. >>>>> >>>>> Some OFBiz experts may disagree with some of my views, and that is okay. >>>>> Different experiences with OFBiz will lead to different viewpoints. >>>>> >>>>> The OFBiz entity caching feature is intended to improve performance by >>>>> keeping GenericValue instances in memory - decreasing the number of calls >>>>> to the database. >>>>> >>>>> Background >>>>> ---------- >>>>> >>>>> Initially, the entity cache was very unreliable due to a number of flaws >>>>> in its design and in the code that calls it (it was guaranteed to produce >>>>> stale data). As a result, I personally avoided using the entity cache >>>>> feature. >>>>> >>>>> Some time ago, Adam Heath did a lot of work on the entity cache. After >>>>> that, Jacopo and I did a lot of work fixing stale data issues in the >>>>> entity >>>>> cache. Today, the entity cache is much improved and unit tests ensure it >>>>> produces the correct data (except for one edge case that Jacopo has >>>>> identified). >>>>> >>>>> I mention all of this because the previous quirky behavior led to some >>>>> "best practices" that didn't make much sense. A search through the OFBiz >>>>> mail archives will produce a mountain of conflicting and confusing >>>>> information. >>>>> >>>>> Today >>>>> ----- >>>>> >>>>> Since the current entity cache is reliable, there is no reason NOT to use >>>>> it. My preference is to make ALL Delegator calls use the cache. If all >>>>> code >>>>> uses the cache, then individual entities can have their caching >>>>> characteristics configured outside of code. This enables sysadmins to >>>>> fine-tune entity caches for best performance. >>>>> >>>>> [Some experts might disagree with this approach because the entity cache >>>>> will consume all available memory. But the idea is to configure the cache >>>>> so that doesn't happen.] >>>>> >>>>> If you code Delegator calls to avoid the cache, then there is no way for >>>>> a >>>>> sysadmin to configure the caching behavior - that bit of code will ALWAYS >>>>> make a database call. >>>>> >>>>> If you make all Delegator calls use the cache, then there is an >>>>> additional >>>>> complication that will add a bit more code: the GenericValue instances >>>>> retrieved from the cache are immutable - if you want to modify them, then >>>>> you will have to clone them. So, this approach can produce an additional >>>>> line of code. >>>>> >>>>> >>>>> -- >>>>> Adrian Crum >>>>> Sandglass Software >>>>> www.sandglass-software.com >>>>> >>>>> >>>> >>>> >>>> >> >> > |
|
|
+1
On Mar 18, 2015, at 5:16 PM, Jacques Le Roux <[hidden email]> wrote: > If a such effort would be undertaken, I'd prefer to go with ehcache: http://ehcache.org/documentation/2.6/get-started/about-distributed-cache > > Jacques > > Le 18/03/2015 14:27, Adrian Crum a écrit : >> I agree there is a lot of overhead with the current distributed cache clearing implementation. From my perspective, that should be changed to use RMI - where the caches talk directly to each other. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 3/18/2015 1:21 PM, Rupert Howell wrote: >>> Yes I'm aware of this. If everything was cached Surely every persist would >>> need to trigger a JMS message telling all the other servers to dump their >>> local cache. This overhead would be big, the amount of messages flying out >>> would be hugely increased and the caches would be redundant anyway because >>> they'd be constantly being dumped. It doesn't seem scalable. >>> >>> On 18 March 2015 at 12:49, Adrian Crum <[hidden email]> >>> wrote: >>> >>>> A clustered environment must use distributed cache clearing. >>>> >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> On 3/18/2015 12:34 PM, Rupert Howell wrote: >>>> >>>>> Hi Adrian, >>>>> >>>>> How would this work in a clustered or load balanced environment? With >>>>> multiple nodes always checking their own local caches incorrect data would >>>>> be persisted all the time. >>>>> >>>>> Regards, >>>>> >>>>> Rupert >>>>> >>>>> On 18 March 2015 at 12:16, Adrian Crum <adrian.crum@sandglass- >>>>> software.com> >>>>> wrote: >>>>> >>>>> I would like to share some insights into the entity cache feature, some >>>>>> best practices I like to follow, and some related information. >>>>>> >>>>>> Some OFBiz experts may disagree with some of my views, and that is okay. >>>>>> Different experiences with OFBiz will lead to different viewpoints. >>>>>> >>>>>> The OFBiz entity caching feature is intended to improve performance by >>>>>> keeping GenericValue instances in memory - decreasing the number of calls >>>>>> to the database. >>>>>> >>>>>> Background >>>>>> ---------- >>>>>> >>>>>> Initially, the entity cache was very unreliable due to a number of flaws >>>>>> in its design and in the code that calls it (it was guaranteed to produce >>>>>> stale data). As a result, I personally avoided using the entity cache >>>>>> feature. >>>>>> >>>>>> Some time ago, Adam Heath did a lot of work on the entity cache. After >>>>>> that, Jacopo and I did a lot of work fixing stale data issues in the >>>>>> entity >>>>>> cache. Today, the entity cache is much improved and unit tests ensure it >>>>>> produces the correct data (except for one edge case that Jacopo has >>>>>> identified). >>>>>> >>>>>> I mention all of this because the previous quirky behavior led to some >>>>>> "best practices" that didn't make much sense. A search through the OFBiz >>>>>> mail archives will produce a mountain of conflicting and confusing >>>>>> information. >>>>>> >>>>>> Today >>>>>> ----- >>>>>> >>>>>> Since the current entity cache is reliable, there is no reason NOT to use >>>>>> it. My preference is to make ALL Delegator calls use the cache. If all >>>>>> code >>>>>> uses the cache, then individual entities can have their caching >>>>>> characteristics configured outside of code. This enables sysadmins to >>>>>> fine-tune entity caches for best performance. >>>>>> >>>>>> [Some experts might disagree with this approach because the entity cache >>>>>> will consume all available memory. But the idea is to configure the cache >>>>>> so that doesn't happen.] >>>>>> >>>>>> If you code Delegator calls to avoid the cache, then there is no way for >>>>>> a >>>>>> sysadmin to configure the caching behavior - that bit of code will ALWAYS >>>>>> make a database call. >>>>>> >>>>>> If you make all Delegator calls use the cache, then there is an >>>>>> additional >>>>>> complication that will add a bit more code: the GenericValue instances >>>>>> retrieved from the cache are immutable - if you want to modify them, then >>>>>> you will have to clone them. So, this approach can produce an additional >>>>>> line of code. >>>>>> >>>>>> >>>>>> -- >>>>>> Adrian Crum >>>>>> Sandglass Software >>>>>> www.sandglass-software.com >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >>> >> |
|
|
In reply to this post by Adrian Crum-3
+1
People often forget that cache memory is hundreds or thousands time faster that disk access or database references. Even with the overhead of distributed cache management. Any extra code required executes at lightspeed rather than rotational speed or even SSD speed. It is also easier to scale CPU than database IO. Removing this sort of decision from application developers to framework coders and database administrators is generally a good idea. Using a standard caching system such as ehcache http://ehcache.org/ is probably the best way to go since it brings a lot of technology to the table and will add a smaller technology TCO to the project even if a custom cache MIGHT give slightly better performance in some cases. Ron On 18/03/2015 10:01 AM, Adrian Crum wrote: > On 3/18/2015 1:46 PM, Jacopo Cappellato wrote: >> On Mar 18, 2015, at 2:35 PM, Adrian Crum >> <[hidden email]> wrote: >> >>> I would be interested in seeing a use case for that. >> >> This is just an example I could think of (there may be other better >> examples but I am in a rush and I can't concentrate): >> >> Client code A selects a bunch of records from TableFoo in order to >> update them; cache is disabled to prevent the creation of cache >> entries that would be expired after a few milliseconds. > > Delegator makes a database call to get the bunch of records. > >> Client code B selects a bunch of records from TableFoo in order to >> format a list in a web page; cache is enabled in order to hit the >> cache after the first visit to the page. > > Delegator makes a database call to get the bunch of records. > > If client code A used the cache, then client code B would not have to > make a database call (or the reverse). > > The problem with your use case is, a developer is trying to determine > the best caching strategy, and that is not something you can decide at > design time. Instead, that is a decision that needs to be made during > staging - where you can measure the real-world effects of concurrent > processes. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
|
|
In reply to this post by Adrian Crum-3
I tend to disagree with the "cache everything" approach because the cache
isn't transaction aware. If you: 1. update a record 2. select that same record 3. encounter a transaction rollback Then the cache will still contain the changes that were rolled back. Regards Scott On Wed, Mar 18, 2015 at 5:16 AM, Adrian Crum < [hidden email]> wrote: > I would like to share some insights into the entity cache feature, some > best practices I like to follow, and some related information. > > Some OFBiz experts may disagree with some of my views, and that is okay. > Different experiences with OFBiz will lead to different viewpoints. > > The OFBiz entity caching feature is intended to improve performance by > keeping GenericValue instances in memory - decreasing the number of calls > to the database. > > Background > ---------- > > Initially, the entity cache was very unreliable due to a number of flaws > in its design and in the code that calls it (it was guaranteed to produce > stale data). As a result, I personally avoided using the entity cache > feature. > > Some time ago, Adam Heath did a lot of work on the entity cache. After > that, Jacopo and I did a lot of work fixing stale data issues in the entity > cache. Today, the entity cache is much improved and unit tests ensure it > produces the correct data (except for one edge case that Jacopo has > identified). > > I mention all of this because the previous quirky behavior led to some > "best practices" that didn't make much sense. A search through the OFBiz > mail archives will produce a mountain of conflicting and confusing > information. > > Today > ----- > > Since the current entity cache is reliable, there is no reason NOT to use > it. My preference is to make ALL Delegator calls use the cache. If all code > uses the cache, then individual entities can have their caching > characteristics configured outside of code. This enables sysadmins to > fine-tune entity caches for best performance. > > [Some experts might disagree with this approach because the entity cache > will consume all available memory. But the idea is to configure the cache > so that doesn't happen.] > > If you code Delegator calls to avoid the cache, then there is no way for a > sysadmin to configure the caching behavior - that bit of code will ALWAYS > make a database call. > > If you make all Delegator calls use the cache, then there is an additional > complication that will add a bit more code: the GenericValue instances > retrieved from the cache are immutable - if you want to modify them, then > you will have to clone them. So, this approach can produce an additional > line of code. > > > -- > Adrian Crum > Sandglass Software > www.sandglass-software.com > |
|
|
That is the edge case I mentioned.
Adrian Crum Sandglass Software www.sandglass-software.com On 3/19/2015 6:54 AM, Scott Gray wrote: > I tend to disagree with the "cache everything" approach because the cache > isn't transaction aware. > If you: > 1. update a record > 2. select that same record > 3. encounter a transaction rollback > > Then the cache will still contain the changes that were rolled back. > > Regards > Scott > > > On Wed, Mar 18, 2015 at 5:16 AM, Adrian Crum < > [hidden email]> wrote: > >> I would like to share some insights into the entity cache feature, some >> best practices I like to follow, and some related information. >> >> Some OFBiz experts may disagree with some of my views, and that is okay. >> Different experiences with OFBiz will lead to different viewpoints. >> >> The OFBiz entity caching feature is intended to improve performance by >> keeping GenericValue instances in memory - decreasing the number of calls >> to the database. >> >> Background >> ---------- >> >> Initially, the entity cache was very unreliable due to a number of flaws >> in its design and in the code that calls it (it was guaranteed to produce >> stale data). As a result, I personally avoided using the entity cache >> feature. >> >> Some time ago, Adam Heath did a lot of work on the entity cache. After >> that, Jacopo and I did a lot of work fixing stale data issues in the entity >> cache. Today, the entity cache is much improved and unit tests ensure it >> produces the correct data (except for one edge case that Jacopo has >> identified). >> >> I mention all of this because the previous quirky behavior led to some >> "best practices" that didn't make much sense. A search through the OFBiz >> mail archives will produce a mountain of conflicting and confusing >> information. >> >> Today >> ----- >> >> Since the current entity cache is reliable, there is no reason NOT to use >> it. My preference is to make ALL Delegator calls use the cache. If all code >> uses the cache, then individual entities can have their caching >> characteristics configured outside of code. This enables sysadmins to >> fine-tune entity caches for best performance. >> >> [Some experts might disagree with this approach because the entity cache >> will consume all available memory. But the idea is to configure the cache >> so that doesn't happen.] >> >> If you code Delegator calls to avoid the cache, then there is no way for a >> sysadmin to configure the caching behavior - that bit of code will ALWAYS >> make a database call. >> >> If you make all Delegator calls use the cache, then there is an additional >> complication that will add a bit more code: the GenericValue instances >> retrieved from the cache are immutable - if you want to modify them, then >> you will have to clone them. So, this approach can produce an additional >> line of code. >> >> >> -- >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> > |
|
|
Ah, it's quite a large edge case IMO
On Thu, Mar 19, 2015 at 12:20 AM, Adrian Crum < [hidden email]> wrote: > That is the edge case I mentioned. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 3/19/2015 6:54 AM, Scott Gray wrote: > >> I tend to disagree with the "cache everything" approach because the cache >> isn't transaction aware. >> If you: >> 1. update a record >> 2. select that same record >> 3. encounter a transaction rollback >> >> Then the cache will still contain the changes that were rolled back. >> >> Regards >> Scott >> >> >> On Wed, Mar 18, 2015 at 5:16 AM, Adrian Crum < >> [hidden email]> wrote: >> >> I would like to share some insights into the entity cache feature, some >>> best practices I like to follow, and some related information. >>> >>> Some OFBiz experts may disagree with some of my views, and that is okay. >>> Different experiences with OFBiz will lead to different viewpoints. >>> >>> The OFBiz entity caching feature is intended to improve performance by >>> keeping GenericValue instances in memory - decreasing the number of calls >>> to the database. >>> >>> Background >>> ---------- >>> >>> Initially, the entity cache was very unreliable due to a number of flaws >>> in its design and in the code that calls it (it was guaranteed to produce >>> stale data). As a result, I personally avoided using the entity cache >>> feature. >>> >>> Some time ago, Adam Heath did a lot of work on the entity cache. After >>> that, Jacopo and I did a lot of work fixing stale data issues in the >>> entity >>> cache. Today, the entity cache is much improved and unit tests ensure it >>> produces the correct data (except for one edge case that Jacopo has >>> identified). >>> >>> I mention all of this because the previous quirky behavior led to some >>> "best practices" that didn't make much sense. A search through the OFBiz >>> mail archives will produce a mountain of conflicting and confusing >>> information. >>> >>> Today >>> ----- >>> >>> Since the current entity cache is reliable, there is no reason NOT to use >>> it. My preference is to make ALL Delegator calls use the cache. If all >>> code >>> uses the cache, then individual entities can have their caching >>> characteristics configured outside of code. This enables sysadmins to >>> fine-tune entity caches for best performance. >>> >>> [Some experts might disagree with this approach because the entity cache >>> will consume all available memory. But the idea is to configure the cache >>> so that doesn't happen.] >>> >>> If you code Delegator calls to avoid the cache, then there is no way for >>> a >>> sysadmin to configure the caching behavior - that bit of code will ALWAYS >>> make a database call. >>> >>> If you make all Delegator calls use the cache, then there is an >>> additional >>> complication that will add a bit more code: the GenericValue instances >>> retrieved from the cache are immutable - if you want to modify them, then >>> you will have to clone them. So, this approach can produce an additional >>> line of code. >>> >>> >>> -- >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> >> |
|
|
I call it an edge case because it is easily fixed by changing the
transaction isolation level. The behavior you describe is not caused by the entity cache, but by the transaction isolation level. The same scenario would exist without the entity cache - where two processes hold a reference to the updated row, and one process performs a rollback. Adrian Crum Sandglass Software www.sandglass-software.com On 3/19/2015 7:28 AM, Scott Gray wrote: > Ah, it's quite a large edge case IMO > > On Thu, Mar 19, 2015 at 12:20 AM, Adrian Crum < > [hidden email]> wrote: > >> That is the edge case I mentioned. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 3/19/2015 6:54 AM, Scott Gray wrote: >> >>> I tend to disagree with the "cache everything" approach because the cache >>> isn't transaction aware. >>> If you: >>> 1. update a record >>> 2. select that same record >>> 3. encounter a transaction rollback >>> >>> Then the cache will still contain the changes that were rolled back. >>> >>> Regards >>> Scott >>> >>> >>> On Wed, Mar 18, 2015 at 5:16 AM, Adrian Crum < >>> [hidden email]> wrote: >>> >>> I would like to share some insights into the entity cache feature, some >>>> best practices I like to follow, and some related information. >>>> >>>> Some OFBiz experts may disagree with some of my views, and that is okay. >>>> Different experiences with OFBiz will lead to different viewpoints. >>>> >>>> The OFBiz entity caching feature is intended to improve performance by >>>> keeping GenericValue instances in memory - decreasing the number of calls >>>> to the database. >>>> >>>> Background >>>> ---------- >>>> >>>> Initially, the entity cache was very unreliable due to a number of flaws >>>> in its design and in the code that calls it (it was guaranteed to produce >>>> stale data). As a result, I personally avoided using the entity cache >>>> feature. >>>> >>>> Some time ago, Adam Heath did a lot of work on the entity cache. After >>>> that, Jacopo and I did a lot of work fixing stale data issues in the >>>> entity >>>> cache. Today, the entity cache is much improved and unit tests ensure it >>>> produces the correct data (except for one edge case that Jacopo has >>>> identified). >>>> >>>> I mention all of this because the previous quirky behavior led to some >>>> "best practices" that didn't make much sense. A search through the OFBiz >>>> mail archives will produce a mountain of conflicting and confusing >>>> information. >>>> >>>> Today >>>> ----- >>>> >>>> Since the current entity cache is reliable, there is no reason NOT to use >>>> it. My preference is to make ALL Delegator calls use the cache. If all >>>> code >>>> uses the cache, then individual entities can have their caching >>>> characteristics configured outside of code. This enables sysadmins to >>>> fine-tune entity caches for best performance. >>>> >>>> [Some experts might disagree with this approach because the entity cache >>>> will consume all available memory. But the idea is to configure the cache >>>> so that doesn't happen.] >>>> >>>> If you code Delegator calls to avoid the cache, then there is no way for >>>> a >>>> sysadmin to configure the caching behavior - that bit of code will ALWAYS >>>> make a database call. >>>> >>>> If you make all Delegator calls use the cache, then there is an >>>> additional >>>> complication that will add a bit more code: the GenericValue instances >>>> retrieved from the cache are immutable - if you want to modify them, then >>>> you will have to clone them. So, this approach can produce an additional >>>> line of code. >>>> >>>> >>>> -- >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> >>> > |
|
|
I'm sorry but I'm not following what you're proposing. Currently row
changes caused within a transaction are available only to queries issued within that same transaction (i.e. read committed), except that the cache breaks this isolation by making them immediately available to any transaction querying that entity. I don't see how this scenario exists outside of the cache unless the logic within the transaction explicitly passes a row off to another transaction, and I'm not aware of any cases like that. On Thu, Mar 19, 2015 at 3:17 AM, Adrian Crum < [hidden email]> wrote: > I call it an edge case because it is easily fixed by changing the > transaction isolation level. > > The behavior you describe is not caused by the entity cache, but by the > transaction isolation level. The same scenario would exist without the > entity cache - where two processes hold a reference to the updated row, and > one process performs a rollback. > > Adrian Crum > Sandglass Software > www.sandglass-software.com > > On 3/19/2015 7:28 AM, Scott Gray wrote: > >> Ah, it's quite a large edge case IMO >> >> On Thu, Mar 19, 2015 at 12:20 AM, Adrian Crum < >> [hidden email]> wrote: >> >> That is the edge case I mentioned. >>> >>> Adrian Crum >>> Sandglass Software >>> www.sandglass-software.com >>> >>> On 3/19/2015 6:54 AM, Scott Gray wrote: >>> >>> I tend to disagree with the "cache everything" approach because the >>>> cache >>>> isn't transaction aware. >>>> If you: >>>> 1. update a record >>>> 2. select that same record >>>> 3. encounter a transaction rollback >>>> >>>> Then the cache will still contain the changes that were rolled back. >>>> >>>> Regards >>>> Scott >>>> >>>> >>>> On Wed, Mar 18, 2015 at 5:16 AM, Adrian Crum < >>>> [hidden email]> wrote: >>>> >>>> I would like to share some insights into the entity cache feature, >>>> some >>>> >>>>> best practices I like to follow, and some related information. >>>>> >>>>> Some OFBiz experts may disagree with some of my views, and that is >>>>> okay. >>>>> Different experiences with OFBiz will lead to different viewpoints. >>>>> >>>>> The OFBiz entity caching feature is intended to improve performance by >>>>> keeping GenericValue instances in memory - decreasing the number of >>>>> calls >>>>> to the database. >>>>> >>>>> Background >>>>> ---------- >>>>> >>>>> Initially, the entity cache was very unreliable due to a number of >>>>> flaws >>>>> in its design and in the code that calls it (it was guaranteed to >>>>> produce >>>>> stale data). As a result, I personally avoided using the entity cache >>>>> feature. >>>>> >>>>> Some time ago, Adam Heath did a lot of work on the entity cache. After >>>>> that, Jacopo and I did a lot of work fixing stale data issues in the >>>>> entity >>>>> cache. Today, the entity cache is much improved and unit tests ensure >>>>> it >>>>> produces the correct data (except for one edge case that Jacopo has >>>>> identified). >>>>> >>>>> I mention all of this because the previous quirky behavior led to some >>>>> "best practices" that didn't make much sense. A search through the >>>>> OFBiz >>>>> mail archives will produce a mountain of conflicting and confusing >>>>> information. >>>>> >>>>> Today >>>>> ----- >>>>> >>>>> Since the current entity cache is reliable, there is no reason NOT to >>>>> use >>>>> it. My preference is to make ALL Delegator calls use the cache. If all >>>>> code >>>>> uses the cache, then individual entities can have their caching >>>>> characteristics configured outside of code. This enables sysadmins to >>>>> fine-tune entity caches for best performance. >>>>> >>>>> [Some experts might disagree with this approach because the entity >>>>> cache >>>>> will consume all available memory. But the idea is to configure the >>>>> cache >>>>> so that doesn't happen.] >>>>> >>>>> If you code Delegator calls to avoid the cache, then there is no way >>>>> for >>>>> a >>>>> sysadmin to configure the caching behavior - that bit of code will >>>>> ALWAYS >>>>> make a database call. >>>>> >>>>> If you make all Delegator calls use the cache, then there is an >>>>> additional >>>>> complication that will add a bit more code: the GenericValue instances >>>>> retrieved from the cache are immutable - if you want to modify them, >>>>> then >>>>> you will have to clone them. So, this approach can produce an >>>>> additional >>>>> line of code. >>>>> >>>>> >>>>> -- >>>>> Adrian Crum >>>>> Sandglass Software >>>>> www.sandglass-software.com >>>>> >>>>> >>>>> >>>> >> |
|
|
Okay, let's assume processes cannot "see" changes made by another
transaction until that transaction is committed. Here is how the current entity cache works: 1. A Delegator find method is invoked. The Delegator checks the cache, and the SQL SELECT result does not exist in the cache. 2. The Delegator executes the SQL SELECT and puts the results in the entity cache. 3. The SQL SELECT results are returned to the calling process. 4. The calling process modifies one of the values (rows) in the SQL SELECT result (after cloning the immutable entity value). 5a. Something goes wrong and the calling process rolls back the transaction before the cloned value is persisted. 5b. Something goes wrong and the calling process rolls back the transaction after the cloned value is persisted and all related caches have been cleared. 6. Another process performs the same query as #1. 7. The second process gets the results from the cache. The values from the cache have not changed because the cloned & modified value (in #4) was not put in the cache, nor was it written to the data source. From my perspective, the scenario you described can only happen if another process can see changes that are made in the data source before the transaction is committed. From your perspective, the entity cache is somehow inserting invalid values when a transaction is rolled back. Adrian Crum Sandglass Software www.sandglass-software.com On 3/19/2015 10:41 AM, Scott Gray wrote: > I'm sorry but I'm not following what you're proposing. Currently row > changes caused within a transaction are available only to queries issued > within that same transaction (i.e. read committed), except that the cache > breaks this isolation by making them immediately available to any > transaction querying that entity. I don't see how this scenario exists > outside of the cache unless the logic within the transaction explicitly > passes a row off to another transaction, and I'm not aware of any cases > like that. > > On Thu, Mar 19, 2015 at 3:17 AM, Adrian Crum < > [hidden email]> wrote: > >> I call it an edge case because it is easily fixed by changing the >> transaction isolation level. >> >> The behavior you describe is not caused by the entity cache, but by the >> transaction isolation level. The same scenario would exist without the >> entity cache - where two processes hold a reference to the updated row, and >> one process performs a rollback. >> >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> >> On 3/19/2015 7:28 AM, Scott Gray wrote: >> >>> Ah, it's quite a large edge case IMO >>> >>> On Thu, Mar 19, 2015 at 12:20 AM, Adrian Crum < >>> [hidden email]> wrote: >>> >>> That is the edge case I mentioned. >>>> >>>> Adrian Crum >>>> Sandglass Software >>>> www.sandglass-software.com >>>> >>>> On 3/19/2015 6:54 AM, Scott Gray wrote: >>>> >>>> I tend to disagree with the "cache everything" approach because the >>>>> cache >>>>> isn't transaction aware. >>>>> If you: >>>>> 1. update a record >>>>> 2. select that same record >>>>> 3. encounter a transaction rollback >>>>> >>>>> Then the cache will still contain the changes that were rolled back. >>>>> >>>>> Regards >>>>> Scott >>>>> >>>>> >>>>> On Wed, Mar 18, 2015 at 5:16 AM, Adrian Crum < >>>>> [hidden email]> wrote: >>>>> >>>>> I would like to share some insights into the entity cache feature, >>>>> some >>>>> >>>>>> best practices I like to follow, and some related information. >>>>>> >>>>>> Some OFBiz experts may disagree with some of my views, and that is >>>>>> okay. >>>>>> Different experiences with OFBiz will lead to different viewpoints. >>>>>> >>>>>> The OFBiz entity caching feature is intended to improve performance by >>>>>> keeping GenericValue instances in memory - decreasing the number of >>>>>> calls >>>>>> to the database. >>>>>> >>>>>> Background >>>>>> ---------- >>>>>> >>>>>> Initially, the entity cache was very unreliable due to a number of >>>>>> flaws >>>>>> in its design and in the code that calls it (it was guaranteed to >>>>>> produce >>>>>> stale data). As a result, I personally avoided using the entity cache >>>>>> feature. >>>>>> >>>>>> Some time ago, Adam Heath did a lot of work on the entity cache. After >>>>>> that, Jacopo and I did a lot of work fixing stale data issues in the >>>>>> entity >>>>>> cache. Today, the entity cache is much improved and unit tests ensure >>>>>> it >>>>>> produces the correct data (except for one edge case that Jacopo has >>>>>> identified). >>>>>> >>>>>> I mention all of this because the previous quirky behavior led to some >>>>>> "best practices" that didn't make much sense. A search through the >>>>>> OFBiz >>>>>> mail archives will produce a mountain of conflicting and confusing >>>>>> information. >>>>>> >>>>>> Today >>>>>> ----- >>>>>> >>>>>> Since the current entity cache is reliable, there is no reason NOT to >>>>>> use >>>>>> it. My preference is to make ALL Delegator calls use the cache. If all >>>>>> code >>>>>> uses the cache, then individual entities can have their caching >>>>>> characteristics configured outside of code. This enables sysadmins to >>>>>> fine-tune entity caches for best performance. >>>>>> >>>>>> [Some experts might disagree with this approach because the entity >>>>>> cache >>>>>> will consume all available memory. But the idea is to configure the >>>>>> cache >>>>>> so that doesn't happen.] >>>>>> >>>>>> If you code Delegator calls to avoid the cache, then there is no way >>>>>> for >>>>>> a >>>>>> sysadmin to configure the caching behavior - that bit of code will >>>>>> ALWAYS >>>>>> make a database call. >>>>>> >>>>>> If you make all Delegator calls use the cache, then there is an >>>>>> additional >>>>>> complication that will add a bit more code: the GenericValue instances >>>>>> retrieved from the cache are immutable - if you want to modify them, >>>>>> then >>>>>> you will have to clone them. So, this approach can produce an >>>>>> additional >>>>>> line of code. >>>>>> >>>>>> >>>>>> -- >>>>>> Adrian Crum >>>>>> Sandglass Software >>>>>> www.sandglass-software.com >>>>>> >>>>>> >>>>>> >>>>> >>> > |
|
|
In reply to this post by Scott Gray-2
The problem with transaction rollback seems to be well understood and different caching strategies are available. Do these references help? http://ehcache.org/generated/2.9.0/html/ehc-all/#page/Ehcache_Documentation_Set%2Fto-tx_transaction_support.html%23 http://ehcache.org/generated/2.9.0/html/ehc-all/#page/Ehcache_Documentation_Set%2Fto-writethrough_and_writebehind_caches.html%23 Ron On 19/03/2015 2:54 AM, Scott Gray wrote: > I tend to disagree with the "cache everything" approach because the cache > isn't transaction aware. > If you: > 1. update a record > 2. select that same record > 3. encounter a transaction rollback > > Then the cache will still contain the changes that were rolled back. > > Regards > Scott > > > On Wed, Mar 18, 2015 at 5:16 AM, Adrian Crum < > [hidden email]> wrote: > >> I would like to share some insights into the entity cache feature, some >> best practices I like to follow, and some related information. >> >> Some OFBiz experts may disagree with some of my views, and that is okay. >> Different experiences with OFBiz will lead to different viewpoints. >> >> The OFBiz entity caching feature is intended to improve performance by >> keeping GenericValue instances in memory - decreasing the number of calls >> to the database. >> >> Background >> ---------- >> >> Initially, the entity cache was very unreliable due to a number of flaws >> in its design and in the code that calls it (it was guaranteed to produce >> stale data). As a result, I personally avoided using the entity cache >> feature. >> >> Some time ago, Adam Heath did a lot of work on the entity cache. After >> that, Jacopo and I did a lot of work fixing stale data issues in the entity >> cache. Today, the entity cache is much improved and unit tests ensure it >> produces the correct data (except for one edge case that Jacopo has >> identified). >> >> I mention all of this because the previous quirky behavior led to some >> "best practices" that didn't make much sense. A search through the OFBiz >> mail archives will produce a mountain of conflicting and confusing >> information. >> >> Today >> ----- >> >> Since the current entity cache is reliable, there is no reason NOT to use >> it. My preference is to make ALL Delegator calls use the cache. If all code >> uses the cache, then individual entities can have their caching >> characteristics configured outside of code. This enables sysadmins to >> fine-tune entity caches for best performance. >> >> [Some experts might disagree with this approach because the entity cache >> will consume all available memory. But the idea is to configure the cache >> so that doesn't happen.] >> >> If you code Delegator calls to avoid the cache, then there is no way for a >> sysadmin to configure the caching behavior - that bit of code will ALWAYS >> make a database call. >> >> If you make all Delegator calls use the cache, then there is an additional >> complication that will add a bit more code: the GenericValue instances >> retrieved from the cache are immutable - if you want to modify them, then >> you will have to clone them. So, this approach can produce an additional >> line of code. >> >> >> -- >> Adrian Crum >> Sandglass Software >> www.sandglass-software.com >> -- Ron Wheeler President Artifact Software Inc email: [hidden email] skype: ronaldmwheeler phone: 866-970-2435, ext 102 |
|
|
In reply to this post by Adrian Crum-3
Le 18/03/2015 13:16, Adrian Crum a écrit :
> If you code Delegator calls to avoid the cache, then there is no way > for a sysadmin to configure the caching behavior - that bit of code > will ALWAYS make a database call. > > If you make all Delegator calls use the cache, then there is an > additional complication that will add a bit more code: the > GenericValue instances retrieved from the cache are immutable - if you > want to modify them, then you will have to clone them. So, this > approach can produce an additional line of code. I don't see any logical reason why we need to keep a GenericValue came from cache as immutable. In large vision, a developper give information on cache or not only he want force the cache using during his process. As OFBiz manage by default transaction, timezone, locale, auto-matching or others. The entity engine would be works with admin sys cache tuning. As example delegator.find("Party", "partyId", partyId) use the default parameter from cache.properties and after the store on a cached GenericValue is a delegator's problem. I see a simple test like that : if (genericValue came from cache) { if (value is already done) { getFromDataBase update Value } else refuse (or not I have a doubt :) ) } store Nicolas |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |