cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Removing "use shared cache" option
Date Mon, 04 Nov 2013 14:32:29 GMT
> Just so it's clear, I'm not opposed to removing non-shared-cache as an
> option.   I just wanted to let you know why I was considering using it
> since you asked.

Of course. Understood. And I appreciate this discussion.

>> I will have to look into that.   I thought when I was doing my testing
>> of changing the qualifiers with a separate ServerRuntime that it used
>> a separate database connection.   Maybe it's just not configured to
>> share the datasource by default.

Yes, this depends on configuration of your stack. JNDIDataSourceFactory will result in a shared
connection pool (provided by container). XMLPoolingDataSourceFactory will not.

>> But if it's < 1Mb per runtime, then it's unlikely it will matter.
>> Since my largest xml data map file is a 256K and contains 75 entities,
>> I assumed that each runtime would also have to load a copy of that
>> data into memory.


Sorry, I missed that part. Copies of DataMap (or more precisely - EntityResolver) will use
some memory. Though EntityResolver can be loaded once and shared between runtimes using a
custom DataDomainProvider or something. 

Andrus


On Nov 4, 2013, at 5:22 PM, Mike Kienenberger <mkienenb@gmail.com> wrote:
> Just so it's clear, I'm not opposed to removing non-shared-cache as an
> option.   I just wanted to let you know why I was considering using it
> since you asked.
> 
> 
> On Mon, Nov 4, 2013 at 9:10 AM, Mike Kienenberger <mkienenb@gmail.com> wrote:
>> On Mon, Nov 4, 2013 at 8:45 AM, Andrus Adamchik <andrus@objectstyle.org> wrote:
>>>> Having separate ServerRuntimes would require separate connections to
>>>> the database, correct? If so, that would not scale well.
>>> 
>>> No. All of them can reuse a single shared DataSource.
>> 
>> I will have to look into that.   I thought when I was doing my testing
>> of changing the qualifiers with a separate ServerRuntime that it used
>> a separate database connection.   Maybe it's just not configured to
>> share the datasource by default.
>> 
>> 
>>>> I'm guessing it would also use quite a bit more memory if each session
>>>> had its own ServerRuntime, depending on the size of your data model.
>>> 
>>> “Use shared cache” creates the most of the memory overhead. Memory overhead
of multiple ServerRuntimes (compared with unchecking "use shared cache”) is only in keeping
clones of various service singletons (factories, etc.). I should probably try it out in profiler
and see what the exact value is, but my wild guess is < 1MB per runtime.
>> 
>> You mean 'Unchecking “Use shared cache” creates the most of the memory
>> overhead', right?
>> 
>> I started to comment on this in my first response, but decided it
>> didn't matter.   There's little point in comparing it against the
>> other memory since that memory use is going to be the same whether
>> it's one or multiple ServerRuntimes, and will depend on the
>> application.    In my use case, the amount of database information
>> pulled in is pretty small per session most of the time.   Maybe one
>> table row from five-to-ten tables and a few table rows from a couple
>> of other tables.   Less often a session might pull in a great deal
>> more data from a lot more tables.
>> 
>> But if it's < 1Mb per runtime, then it's unlikely it will matter.
>> Since my largest xml data map file is a 256K and contains 75 entities,
>> I assumed that each runtime would also have to load a copy of that
>> data into memory.
> 


Mime
View raw message