I had a quick look on the Persistence code for Infinispan yesterday, and it looks like the JBoss Messaging Journal was just made for infinispan. The only thing I couldn' t understand was the streaming operations fromStream and toStream. What they are used for, and how they translate into multiple records? We have talked about making the Journal a sub project of JBoss Messaging, in a way other projects would be able to reuse (if that interests you guys). Cheers, Clebert _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

I don' t know if this is what you asked, but all you need is to provide a CacheStore implementation for the JBMJournal, just like you do for JDBC, and BDB Java. on the JBM case, we also have our equivalent to your CacheStore. We call it StorageManager. http://anonsvn.jboss.org/repos/messaging/trunk/src/main/org/jboss/messagi... The Journal itself don' t have any dependency on Messaging: http://anonsvn.jboss.org/repos/messaging/trunk/src/main/org/jboss/messagi...

> Shouldn't this be a part of JBoss Commons then? Or maybe some > independent project - JBoss Journal? > That will happen. It started as part of JBM.. and we are talking about making it separated. We made sure we would keep it independent, so we would be able to eventually split it.

Just one question (that was on the original post) What is this fromStrem and toStream. How they translate to records? if you exaplain how it works on the BDB example... I will know how to translate that to the JBMJournal example.

Last time this was discussed, it was mentioned that the journal does not provide random access. Is this still the case? In order for a cache store/loader to be useful, it needs to offer an indexing mechanism. Clebert Suconic wrote: > I had a quick look on the Persistence code for Infinispan yesterday, > and it looks like the JBoss Messaging Journal was just made for > infinispan. > > > The only thing I couldn' t understand was the streaming operations > fromStream and toStream. What they are used for, and how they > translate into multiple records? > > > We have talked about making the Journal a sub project of JBoss > Messaging, in a way other projects would be able to reuse (if that > interests you guys). > > > > Cheers, > > > > Clebert > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev

Yes - the cache store stores a superset of what is in memory. Overflow. So it still needs to be accessible in a random fashion, using a key. See the load() API on the CacheLoader interface.

On 30 Jul 2009, at 18:12, Clebert Suconic wrote: > >> Yes - the cache store stores a superset of what is in memory. >> Overflow. So it still needs to be accessible in a random fashion, >> using a key. >> >> See the load() API on the CacheLoader interface. > > > If the data is in memory, why do you need to recover it from the Store? Eviction. Restarts. Etc. :) -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org

On restarts, you can get the whole data back on the method load. Eviction is probably a delete. so you probably don' t need to read the Store for eviction. On 07/30/2009 12:16 PM, Manik Surtani wrote: > > On 30 Jul 2009, at 18:12, Clebert Suconic wrote: > >> >>> Yes - the cache store stores a superset of what is in memory. >>> Overflow. So it still needs to be accessible in a random fashion, >>> using a key. >>> >>> See the load() API on the CacheLoader interface. >> >> >> If the data is in memory, why do you need to recover it from the Store? > > Eviction. Restarts. Etc. :) > > -- > Manik Surtani > manik(a)jboss.org > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > >

Well .. ok.. it doesn' t fit on that at the moment. On 07/30/2009 12:29 PM, Jason T. Greene wrote: > The cache store is/can be a superset of the data in memory. So, for > example, you may have 1G of data, but only 200M of memory. You can > configure the memory part of the cache to be an LRU (data is never > lost, just evicted from memory). > > Even if the disk storage fits in memory, you likely don't want to load > it right away if you dont have to (i.e. waiting on 2 gigs of disk to > be read in) > > > > Clebert Suconic wrote: >> On restarts, you can get the whole data back on the method load. >> >> Eviction is probably a delete. so you probably don' t need to read >> the Store for eviction. >> >> >> >> >> On 07/30/2009 12:16 PM, Manik Surtani wrote: >>> >>> On 30 Jul 2009, at 18:12, Clebert Suconic wrote: >>> >>>> >>>>> Yes - the cache store stores a superset of what is in memory. >>>>> Overflow. So it still needs to be accessible in a random fashion, >>>>> using a key. >>>>> >>>>> See the load() API on the CacheLoader interface. >>>> >>>> >>>> If the data is in memory, why do you need to recover it from the >>>> Store? >>> >>> Eviction. Restarts. Etc. :) >>> >>> -- >>> Manik Surtani >>> manik(a)jboss.org >>> Lead, Infinispan >>> Lead, JBoss Cache >>> http://www.infinispan.org >>> http://www.jbosscache.org >>> >>> >>> >>> >> > >

So in otherwords, the equivalent of a BDB Hash or Recno type would work. Jason T. Greene wrote: > BUT.... :) If you had a random access file (just integer offsets is > all that is needed), combined with this journal, you could create a > simple record based transaction db, and that could definitely be > mapped. The key hash could be used to map to a block that would > contain near entries. > > Clebert Suconic wrote: >> Well .. ok.. it doesn' t fit on that at the moment. >> >> On 07/30/2009 12:29 PM, Jason T. Greene wrote: >>> The cache store is/can be a superset of the data in memory. So, for >>> example, you may have 1G of data, but only 200M of memory. You can >>> configure the memory part of the cache to be an LRU (data is never >>> lost, just evicted from memory). >>> >>> Even if the disk storage fits in memory, you likely don't want to >>> load it right away if you dont have to (i.e. waiting on 2 gigs of >>> disk to be read in) >>> >>> >>> >>> Clebert Suconic wrote: >>>> On restarts, you can get the whole data back on the method load. >>>> >>>> Eviction is probably a delete. so you probably don' t need to read >>>> the Store for eviction. >>>> >>>> >>>> >>>> >>>> On 07/30/2009 12:16 PM, Manik Surtani wrote: >>>>> >>>>> On 30 Jul 2009, at 18:12, Clebert Suconic wrote: >>>>> >>>>>> >>>>>>> Yes - the cache store stores a superset of what is in memory. >>>>>>> Overflow. So it still needs to be accessible in a random >>>>>>> fashion, using a key. >>>>>>> >>>>>>> See the load() API on the CacheLoader interface. >>>>>> >>>>>> >>>>>> If the data is in memory, why do you need to recover it from the >>>>>> Store? >>>>> >>>>> Eviction. Restarts. Etc. :) >>>>> >>>>> -- >>>>> Manik Surtani >>>>> manik(a)jboss.org >>>>> Lead, Infinispan >>>>> Lead, JBoss Cache >>>>> http://www.infinispan.org >>>>> http://www.jbosscache.org >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >> > >