Infinispan-dev

Popular Threads From Infinispan-dev:

ISPN-359 and grouping entries for distribution

Native CacheStore implementation?

ISPN 200

CR3: async stores, again

Why is loading from store needed before storing in cache store?

List Statistics

Total Threads: 543
Total Posts: 1196

Phrases Used to Find This Thread

Page 1 of 1

12-10-2010 02:33 PM

Infinispan-dev member admin is online now

User

12-10-2010 02:37 PM

Infinispan-dev member admin is online now

User

12-10-2010 02:44 PM

Infinispan-dev member admin is online now

User

12-10-2010 02:47 PM

Infinispan-dev member admin is online now

User

12-10-2010 02:53 PM

Infinispan-dev member admin is online now

User

12-10-2010 02:55 PM

Infinispan-dev member admin is online now

User

12-10-2010 04:30 PM

Infinispan-dev member admin is online now

User

12-10-2010 05:43 PM

Infinispan-dev member admin is online now

User

14-10-2010 08:32 AM

Infinispan-dev member admin is online now

User

#10

14-10-2010 12:39 PM

Infinispan-dev member admin is online now

User

#11

14-10-2010 03:10 PM

Infinispan-dev member admin is online now

User

#12

15-10-2010 05:43 AM

Infinispan-dev member admin is online now

User

#13

15-10-2010 12:40 PM

Infinispan-dev member admin is online now

User

Hi,

Currently, we have two local CacheStore implementations - BDBJE and JDBM.

If someone distributes an application that uses BDBJE, that application
must be under an open source license. It's not a problem to Infinispan,
but it is to our users who want to distribute Infinispan with their
applications and want to use BDBJE as a backend.

JDBM has one of the most permissive license, but the recent
investigation revealed a significant performance issue:

https://jira.jboss.org/browse/ISPN-663

Moreover, JDBM hasn't been maintained actively for a long time.

If we write our own native CacheStore implementation that is optimized
for our CacheStore API, we will be able to present the whole new
performance numbers to wider audience.

WDYT?

--
http://gleamynode.net/ On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)" <>wrote:

> Currently, we have two local CacheStore implementations - BDBJE and JDBM.
>

Correction: there is also the FileCacheStore.

Tristan I might also add that the Cassandra CacheStore has good performance (well,
Cassandra does :))

Tristan

On Tue, Oct 12, 2010 at 15:37, Tristan Tarrant <>wrote:

> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)" <>wrote:
>
>> Currently, we have two local CacheStore implementations - BDBJE and JDBM.
>>
>
> Correction: there is also the FileCacheStore.
>
> Tristan
> Tristan Tarrant wrote:
> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)" <
> > 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?

--
http://gleamynode.net/ >
> 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?
>
> Haven't tried BDBJE, but it certainly is faster than JDBM. We should setup
Hudson's performance plugin

http://wiki.hudson-ci.org/display/HUDSON/Performance+Plugin

so we can monitor regressions.

Tristan Yeah, I omitted it however because it brings another level of
abstraction. NoSQL over NoSQL... :-)

Tristan Tarrant wrote:
> I might also add that the Cassandra CacheStore has good performance
> (well, Cassandra does :))
>
> Tristan
>
> On Tue, Oct 12, 2010 at 15:37, Tristan Tarrant
> < > wrote:
>
> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)"
> < > wrote:
>
> Currently, we have two local CacheStore implementations - BDBJE
> and JDBM.
>
>
> Correction: there is also the FileCacheStore.
>
> Tristan
>
>
>
>
> _______________________________________________
___________________________________________________

Posted on the Infinispan-dev mailing list. Go to https://lists.jboss.org/mailman/listinfo/infinispan-dev to subscribe. 2010/10/12 Tristan Tarrant <>:
>> 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?
>>
> Haven't tried BDBJE, but it certainly is faster than JDBM.

My finding so far - FileCacheStore is a BucketBasedCacheStore that uses
the hashCode of the key as the bucket name. FileCacheStore creates a
new file for each bucket. It means a lot of files will be created as
new entries are added. I don't think it will perform better than JDBM
or BDBJE in most cases.

--
http://gleamynode.net/ On 12 Oct 2010, at 14:47, 이희승 (Trustin Lee) wrote:

> Tristan Tarrant wrote:
>> On Tue, Oct 12, 2010 at 15:33, "이희승 (Trustin Lee)" <
>> > 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.
> --
> http://gleamynode.net/
>
> _______________________________________________
___________________________________________________

Posted on the Infinispan-dev mailing list. Go to https://lists.jboss.org/mailman/listinfo/infinispan-dev to subscribe. 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)" <
>>> > 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?

I suppose you'd be targeting the local cache store space and not the shared one, 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.

>> --
>> http://gleamynode.net/
>>
>> _______________________________________________
___________________________________________________

Posted on the Infinispan-dev mailing list. Go to https://lists.jboss.org/mailman/listinfo/infinispan-dev to subscribe. 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)" <
>>>> > 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/ 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)" <
>>>>> > 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/
>
>
> _______________________________________________
___________________________________________________

Posted on the Infinispan-dev mailing list. Go to https://lists.jboss.org/mailman/listinfo/infinispan-dev to subscribe. On Tue, Oct 12, 2010 at 6:33 AM, "이희승 (Trustin Lee)" <> wrote:

> JDBM has one of the most permissive license, but the recent
> investigation revealed a significant performance issue:
>
> https://jira.jboss.org/browse/ISPN-663
>
> Moreover, JDBM hasn't been maintained actively for a long time.

Just a note: JDBM has been effectively forked (or continued?) and is
hosted here:

http://jdbm2.googlecode.com/

The new lead on the project has done a number of performance
improvements. Since I worked on the original JDBM CacheStore, I was
considering doing an update to version 2. Still, there are performance
issues to address in JDBM, e.g.
http://code.google.com/p/jdbm2/issues/detail?id=1 and the JDBM 2 is
still in Beta.

I also came up, before JBossCache was effectively abandoned, a new
cache operation: TreeCache.store(K, Map) which did not return the
existing value. Also, TreeCache.clear(K). These were substitutes for
put and remove in 99% of cases when the return value is not of use.
I'm not sure these would necessarily fit into the Infinispan API, but
they are a lot easier for end users to understand what they do and
they are a lot more efficient.

_______________________________________________
___________________________________________________

Posted on the Infinispan-dev mailing list. Go to https://lists.jboss.org/mailman/listinfo/infinispan-dev to subscribe. On Oct 15, 2010, at 1:50 AM, Sanne Grinovero wrote:

> actually I consider it a mayor value that there are many stores available.
> sure performance is important, but on cloud you might love to use S3
> for flexibility reasons (for example it easy to manage).

Sure, that's already covered with JClouds based cache store. It's called cloud cache store :)

>
> Also in some companies they just have "policies" which aren't easy to
> change, a quite frequent one reads
>
> *"all state shall be stored in Oracle"*
>
> Developers might have many different reasons to oppose these rule, but
> no way, if your app is going
> to store critical information in the filesystem (or whatever else your
> propose which is not the DB) it's not going to be set in production -
> no way for that.
>
> Of course, this reflects just my limited experience, a speedy version
> would be cool, but it has to be damn fast to be of any interest,
> and I'd prefer to have all existing implementations "tuned" as far as
> possible (including the Cassandra one, which seems to fit nicely as a
> potential native speedy implementation..).
>
> Cheers,
> Sanne
>
> 2010/10/14 Galder Zamarreño <>:
>>
>> On Oct 14, 2010, at 4:10 PM, Mircea Markus wrote:
>>
>>>
>>> On 14 Oct 2010, at 12:39, 이희승 (Trustin Lee) wrote:
>>>
>>>>
>>>>
>>>> Galder Zamarreño wrote:
>>>>
>>>>> 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
>>
>> I don't think that's totally right actually. JBoss AS has been using the FileCacheStore in JBoss Cache for EJB3 SFSB passivation and HTTP session passivation and afaik, I haven't heard any complaints from them.
>>
>> So, there must be something right about it and we're not talking about sporadic use here. Remember that this is actually part of the supported EAP 5.x as well.
>>
>> Granted that using FCS as shared cache store is crazy, but there's a valid use for local use.
>>
>> FYI: https://svn.jboss.org/repos/jbossas/tags/JBPAPP_5_1_0_GA/cluster/src/resources/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml
>>
>> --
>> Galder Zamarreño
>> Sr. Software Engineer
>> Infinispan, JBoss Cache
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the Infinispan-dev mailing list. Go to https://lists.jboss.org/mailman/listinfo/infinispan-dev to subscribe.

#14

18-10-2010 10:15 AM

Infinispan-dev member admin is online now

User

#15

18-10-2010 10:28 AM

Infinispan-dev member admin is online now

User

#16

18-10-2010 05:29 PM

Infinispan-dev member admin is online now

User

#17

18-10-2010 06:44 PM

Infinispan-dev member admin is online now

User

#18

19-10-2010 02:40 AM

Infinispan-dev member admin is online now

User

#19

19-10-2010 08:30 AM

Infinispan-dev member admin is online now

User

#20

25-10-2010 12:47 PM

Infinispan-dev member admin is online now

User

Page 1 of 1

NewsArc Lists | Culture Pages | Computing Archive | Media-Pages

Link to this page on your blog or website by copying the HTML code below and pasting it into your site:

Next Thread »