[ 
https://issues.apache.org/jira/browse/CAMEL-12041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16288976#comment-16288976
 ] 

Marc Carter commented on CAMEL-12041:
-------------------------------------

Yes these are small and easily reproducible by individual developers (I did it) 
but it's interfacing Camel to the Java API - I see that as something that Camel 
should do on behalf of _all_ developers (hence PR).

If a developer wishes to use any given persistent map technology (MapDB, 
Chronicle Map etc), all that is needed is to wrap the (Java API) Map or 
ConcurrentMap interface provided by those libraries. No provider-specific camel 
code is required.

MapIdempotentRepository - wraps any Map. This already existed in 
MemoryIdempotentRepository but Map != memory in such cases so I felt it more 
correct to tease these apart and also to name it using the well-known Java API 
name.
ConcurrentMapIdempotentRepository - wraps any ConcurrentMap and is a basic 
performance enhancement over MapIR as it does away with explicit locking. 

I hope this is clear enough as I will eventually submit a similar item relating 
to AggregationRepository.

> Introduce ConcurrentMapIdempotentRepository and MapIdempotentRepository
> -----------------------------------------------------------------------
>
>                 Key: CAMEL-12041
>                 URL: https://issues.apache.org/jira/browse/CAMEL-12041
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-core
>    Affects Versions: 2.20.1
>            Reporter: Marc Carter
>            Priority: Trivial
>
> In order to more generically plug in third-party data fabrics, Camel should 
> directly support the ConcurrentMap interface.
> 1 Add an explicit ConcurrentMapIdempotentRepository (which does away with 
> synchronized blocks around the backing map) 
> 2 Factor our MapIdempotentRepository from MemoryIdempotentRepository (being 
> based on a Map _interface_ doesn't make it "memory" - only the default 
> LRUCache impls are definitively "memory")
> 3 Make some sense of the tests around this EIP



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to