Hi,
I had plans to integrate it with simplestore, for transactional storage,
  but it seems I don't  understand  license. I know MySQL server use it for 
transactional tables.

At 10:08 PM 1/29/2002 -0500, you wrote:
>Thanks for the sleepycat link.  Looks good but the license is close to
>GPL.  It may be ok if the redistribution clause only goes 1 level.  JCS
>would be the app, the app using JCS would not could as redistributing
>sleepycat.  I doubt it though.
>
>Aaron
>
> > -----Original Message-----
> > From: Juozas Baliuka [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, January 29, 2002 3:40 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: JISP, cache
> >
> > At 01:33 AM 1/29/2002 -0500, you wrote:
> > >What kind of performance are you getting from JISP?
> > >
> > >For JCS I tried using a generic key that would take a serialized
>object
> > >and compared on the hashcode and the performance is not so great.  I
>ran
> > >jprobe on it and the io is the bottleneck.  The hashcode was
> > >insignificant. . . .  Maybe I'm too tired to see the problem.
> >   I don't tried JISP, I think there are a lot of BTree
>implementations,
> > and
> > user
> > can choose one, may be JISP or his implementation. I know NetBeans
>have
> > some implementation
> > may be it is the same JISP, I saw JDO RI use it. Berkeley DB is very
> > powerful for this kind of storage
> > http://sleepycat.com , and believe there are more implementations .
> >   But we don't have open source stress tools, I think this is the main
> > problem,
> > I have no budget for simplestore to buy  jprobe and its sources.
> >
> >
> >
> >
> > >How much memory is it using for the keys and index?
> > >
> > >Keys are pretty cheap.  If you can keep them in memory and store the
> > >values on disk, you can get a tremendous performance boost.  I did
>this
> > >for one of the disk cache auxiliaries in JCS. . . .
> >
> > Yes, it is good idea to have index in memory for BTree implementation
> >
> >
> >
> > >Hmmn.
> > >
> > >Aaron
> > >
> > >
> > >
> > >
> > >--
> > >To unsubscribe, e-mail:   <mailto:commons-dev-> 
> [EMAIL PROTECTED]>
> > >For additional commands, e-mail: <mailto:commons-dev-> 
> [EMAIL PROTECTED]>
> >
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:commons-dev-> 
> [EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:commons-dev-> 
> [EMAIL PROTECTED]>
>
>
>--
>To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to