[infinispan-dev] Native CacheStore implementation?

[Mircea Markus]

On 14 Oct 2010, at 12:39, 이희승 (Trustin Lee) wrote:

> 
> 
> Galder Zamarreño wrote:
>> On Oct 12, 2010, at 6:43 PM, Mircea Markus wrote:
>> 
>>> On 12 Oct 2010, at 14:47, 이희승 (Trustin Lee) wrote:
>>> 
>>>> Tristan Tarrant wrote:
>>>>> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)" <trustin at gmail.com
>>>>> <mailto:trustin at gmail.com>> wrote:
>>>>> 
>>>>>  Currently, we have two local CacheStore implementations - BDBJE and
>>>>>  JDBM.
>>>>> 
>>>>> 
>>>>> Correction: there is also the FileCacheStore. 
>>>> You are right.  I missed that, argh! :)
>>>> 
>>>> How does it perform then comparing to BDBJE and JDBM?  Out of curiosity,
>>>> if there is a good file-based cache store implementation, why BDBJE and
>>>> JDBM backends were introduced?
>>> One reason is that FileCacheStore is not good with transactions.Transactions & cache stores will get more attention in 5.0. Also FileCacheStore is a BucketBasedCacheStore which might not be good if keys hash in the same bucket.
>>> I like your idea of native cache store though, and I think as long as we can outperform the other stores we should only maintain that one.
>> 
>> Trustin/Mircea,
>> 
>> What exactly do you guys mean by 'native'? Something like what HornetQ guys did? Or your talking more about adapting an existing cache store impl library to suit our type of ops? 
> 
> Something similar to the latter.  Basically, I think we need to replace
> the current FileCacheStore implementation.  We could utilize what
> HornetQ guys did with libaio if that will yield even higher performance,
> but it's not the first task to do.
Same here! I would like to be able to supply users a very fast cache store that would come out of the box. I.e. no need to install a DB etc.
> 
>> I suppose you'd be targeting the local cache store space and not the shared one, correct?
> 
> Correct.
> 
>> I do have some doubts on whether spending time implementing another cache store impl would be really that useful.
>> 
>> When I was in Berlin, rather than implementing another X cache store due to performance, I heard users asking more about whether they could have their existing databases be read by Infinispan cache stores, to avoid having multiple databases, one for a shared JDBC cache store and one for their JPA or similar ORM databases. Granted that this could be done with a Hibernate based cache store but then again you could be wondering whether they should not just use Hibernate directly with a 2LC.
> 
> I think that depends on how solid and fast FileCacheStore is.  If it's
> good, more people will use it.  For now, not many people seem to use it
> and that might be why we don't hear much about it.
We explicitly  discourage people to use file cache store:  http://community.jboss.org/wiki/CacheLoaders#Shipped_Implementations
> 
> Also, having a good reference local cache store implementation is
> important to initial adoption, because people will find better numbers
> when they evaluate Infinispan.  
> They could begin their tests with other
> cache stores like JdbcCacheStore, but most people will start with the
> most easy-to-configure one with the least dependency.
+1 
Not something urgent IMO, but I think it's worth keeping it in mind as this is something that can easily be passed to a potential contributor.
> 
> Just my 2 cents. :)
> 
> -- 
> Trustin Lee - http://gleamynode.net/
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101014/4b177382/attachment.html