Re: Adding new dependencies for in-core

On Jun 30, 2015, at 11:14 AM, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> wrote:

>> I'm having trouble believing any end user will replace the caching strategy for prepared statements.
>
> My wild guess is Markus a bit over-engineers _internal_ implementation
> of the driver.
> I think he hints best practices of coding so the driver does not get
> tied to the single cache implementation.
> Markus, did I get you right?

I am not opposed to hiding this behind an interface, but unless we expose this cache to the end user (which IMO we should not, barring a compelling reason) it is not hard to replace it internally even if it breaks the not-public-API. So the interface just adds complexity for no real gain unless we actually expect to switch it out at runtime.

Additionally, the ConcurrentMap interface doesn't really have any "removeLRU" sorts of functionality, so it's not clear that it is the proper interface anyway.

Final note, is a ConcurrentLinkedHashMap actually the data structure we should be using? The "linked" part enforces that the removal strategy is not LRU, it is actually FIFO. So an incoming query may evict the oldest entry, which could very well be the most used entry. Maybe this is not a problem in practice but I thought I'd point it out.