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

I'm having trouble believing any end user will replace the caching strategy for prepared statements.  Maybe one or two
Gentoorefugees 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