On Jun 30, 2015, at 11:14 AM, Vladimir Sitnikov <sitnikov.vladimir@gmail.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
shouldnot, barring a compelling reason) it is not hard to replace it internally even if it breaks the not-public-API.
Sothe 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
thatit is the proper interface anyway.
Final note, is a ConcurrentLinkedHashMap actually the data structure we should be using? The "linked" part enforces
thatthe removal strategy is not LRU, it is actually FIFO. So an incoming query may evict the oldest entry, which could
verywell be the most used entry. Maybe this is not a problem in practice but I thought I'd point it out.