Re: Adding new dependencies for in-core - Mailing list pgsql-jdbc

I also do not think an END USER will do that, but WE (i. e. pgjdbc
developers) might one day like to experiment with other caching strategies.
:-)


-----Original Message-----
From: Steven Schlansker [mailto:stevenschlansker@gmail.com]
Sent: Dienstag, 30. Juni 2015 20:10
To: Markus KARG
Cc: List
Subject: Re: [JDBC] Adding new dependencies for in-core

I'm having trouble believing any end user will replace the caching strategy
for prepared statements.  Maybe one or two Gentoo refugees will, and they
will probably misconfigure it horribly anyway ;)

On Jun 30, 2015, at 10:56 AM, Markus KARG <markus@headcrashing.eu> wrote:

> I see. Just to throw in a different idea: Possibly we might need caches in
> other places too at a later time, so maybe we might like to apply strategy
> design pattern instead of becoming directly dependent of one particular
> class? I mean, it is nice that the linked hash map actually implies LRU,
but
> if we want LRU, it might be a better design choice, to explicitly model
this
> as a class "LruCacheStrategy" which allows us to even configure or replace
> the strategy later?
>
> -----Original Message-----
> From: Steven Schlansker [mailto:stevenschlansker@gmail.com]
> Sent: Dienstag, 30. Juni 2015 19:09
> To: Markus KARG
> Cc: List
> Subject: Re: [JDBC] Adding new dependencies for in-core
>
> It is a Concurrent *Linked* HashMap, which presumably facilitates LRU
> removal.
>
> On Jun 30, 2015, at 10:06 AM, Markus KARG <markus@headcrashing.eu> wrote:
>
>> Vladimir,
>>
>> sorry for being so ingorant not to give it a deeper thought, but what is
> in CLHM what is not also in java.util.concurrent.ConcurrentHashMap?
>>
>> -Markus
>>
>> -----Original Message-----
>> From: pgsql-jdbc-owner@postgresql.org
> [mailto:pgsql-jdbc-owner@postgresql.org] On Behalf Of Vladimir Sitnikov
>> Sent: Dienstag, 30. Juni 2015 14:21
>> To: List
>> Subject: [JDBC] Adding new dependencies for in-core
>>
>> Hi,
>>
>> I've had a quick look into https://github.com/pgjdbc/pgjdbc/issues/345
>> (Share parsed query texts across different connections) and it looks like
> https://github.com/ben-manes/concurrentlinkedhashmap would be useful to
> implement the cache.
>>
>> We don't need all the stuff CLHM has, but I see no easy&scalable way of
> doing concurrent map with eviction by mere java.util.concurrent stuff.
>>
>> Well, I can do lock splitting (i.e. use multiple small LRU caches instead
> of a single big cache), however that looks like reinventing the wheel.
>>
>> Can you suggest what is the best way of adding CLHM dependency?
>> Should it be added in plain?
>> Should it be shaded? (i.e. renamed to org.postgresql.clhm...)
>>
>> I'm more inclined to the "add regular dependency" approach.
>>
>> I expect similar question might appear if we consider using netty for IO.
>>
>> --
>> Regards,
>> Vladimir Sitnikov
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>>
>>
>>
>> --
>> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-jdbc
>
>
>
>
> --
> Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-jdbc