[infinispan-dev] Native CacheStore implementation?

"이희승 (Trustin Lee)" trustin at gmail.com
Thu Oct 14 07:39:14 EDT 2010



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.

> 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.

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.

Just my 2 cents. :)

-- 
Trustin Lee - http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 290 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101014/c17e421f/attachment.bin 


More information about the infinispan-dev mailing list