You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Andrew McIntyre <mc...@gmail.com> on 2006/08/08 05:55:00 UTC

Re: In Memory

On 7/31/06, Chris Forbis <ch...@symantec.com> wrote:
>
>
> I was looking at derby and the FAQ says in Memory version has not been
> completed, but to check with list..  It also said this about six months ago
> :)  Just wondering if anything is being done on it...

This feature request is being tracked with DERBY-646 in JIRA:

http://issues.apache.org/jira/browse/DERBY-646

Feel free to pick up the work that has been done there and continue it
if you are interested. There are comments in JIRA that describe what
work remains to be done.

If you are not interested in working on the feature, and the
durability of your databases is not concern for you, then you could
achieve similar performance by running with the property
derby.system.durability set to "test":

http://db.apache.org/derby/docs/dev/tuning/rtunproperdurability.html

HTH,
andrew

Re: In Memory

Posted by David Van Couvering <Da...@Sun.COM>.
I actually wasn't trying to make look DERBY-646 look better.  I should 
have been more clear.  There was a durability mode we were talking about 
that would be loosy-goosy about writing the log to disk, while at the 
same time guaranteeing database consistency.  You could potentially lose 
the last N transactions on a crash, but your database would be rebootable.

David

Mike Matrigali wrote:
> 
> 
> David Van Couvering wrote:
>> FYI, the issue with "durability:test" is not that you may lose some 
>> data, it's that your data may become corrupt on failure and you won't 
>> be able to reboot it.  This is fine for unit testing, that's why it's 
>> called "test".
> 
> I am not quite sure what point you are trying to make here.
> It seems that you are saying DERBY-646 has less problems than 
> durability=test.  With in memory you are guaranteed to lose your
> database on reboot (which may be just fine for some apps).
> 
>>
>> DERBY-646 needs to be tested and documented.  It sure would be nice to 
>> get this in there, we keep getting this request.
>>
>> David
>>
>> Andrew McIntyre wrote:
>>
>>> On 7/31/06, Chris Forbis <ch...@symantec.com> wrote:
>>>
>>>>
>>>>
>>>> I was looking at derby and the FAQ says in Memory version has not been
>>>> completed, but to check with list..  It also said this about six 
>>>> months ago
>>>> :)  Just wondering if anything is being done on it...
>>>
>>>
>>> This feature request is being tracked with DERBY-646 in JIRA:
>>>
>>> http://issues.apache.org/jira/browse/DERBY-646
>>>
>>> Feel free to pick up the work that has been done there and continue it
>>> if you are interested. There are comments in JIRA that describe what
>>> work remains to be done.
>>>
>>> If you are not interested in working on the feature, and the
>>> durability of your databases is not concern for you, then you could
>>> achieve similar performance by running with the property
>>> derby.system.durability set to "test":
>>>
>>> http://db.apache.org/derby/docs/dev/tuning/rtunproperdurability.html
>>>
>>> HTH,
>>> andrew
>>
>>
>>
> 

Re: In Memory

Posted by Mike Matrigali <mi...@sbcglobal.net>.

David Van Couvering wrote:
> FYI, the issue with "durability:test" is not that you may lose some 
> data, it's that your data may become corrupt on failure and you won't be 
> able to reboot it.  This is fine for unit testing, that's why it's 
> called "test".

I am not quite sure what point you are trying to make here.
It seems that you are saying DERBY-646 has less problems than 
durability=test.  With in memory you are guaranteed to lose your
database on reboot (which may be just fine for some apps).

> 
> DERBY-646 needs to be tested and documented.  It sure would be nice to 
> get this in there, we keep getting this request.
> 
> David
> 
> Andrew McIntyre wrote:
> 
>> On 7/31/06, Chris Forbis <ch...@symantec.com> wrote:
>>
>>>
>>>
>>> I was looking at derby and the FAQ says in Memory version has not been
>>> completed, but to check with list..  It also said this about six 
>>> months ago
>>> :)  Just wondering if anything is being done on it...
>>
>>
>> This feature request is being tracked with DERBY-646 in JIRA:
>>
>> http://issues.apache.org/jira/browse/DERBY-646
>>
>> Feel free to pick up the work that has been done there and continue it
>> if you are interested. There are comments in JIRA that describe what
>> work remains to be done.
>>
>> If you are not interested in working on the feature, and the
>> durability of your databases is not concern for you, then you could
>> achieve similar performance by running with the property
>> derby.system.durability set to "test":
>>
>> http://db.apache.org/derby/docs/dev/tuning/rtunproperdurability.html
>>
>> HTH,
>> andrew
> 
> 
> 


Re: In Memory

Posted by David Van Couvering <Da...@Sun.COM>.
FYI, the issue with "durability:test" is not that you may lose some 
data, it's that your data may become corrupt on failure and you won't be 
able to reboot it.  This is fine for unit testing, that's why it's 
called "test".

DERBY-646 needs to be tested and documented.  It sure would be nice to 
get this in there, we keep getting this request.

David

Andrew McIntyre wrote:
> On 7/31/06, Chris Forbis <ch...@symantec.com> wrote:
>>
>>
>> I was looking at derby and the FAQ says in Memory version has not been
>> completed, but to check with list..  It also said this about six 
>> months ago
>> :)  Just wondering if anything is being done on it...
> 
> This feature request is being tracked with DERBY-646 in JIRA:
> 
> http://issues.apache.org/jira/browse/DERBY-646
> 
> Feel free to pick up the work that has been done there and continue it
> if you are interested. There are comments in JIRA that describe what
> work remains to be done.
> 
> If you are not interested in working on the feature, and the
> durability of your databases is not concern for you, then you could
> achieve similar performance by running with the property
> derby.system.durability set to "test":
> 
> http://db.apache.org/derby/docs/dev/tuning/rtunproperdurability.html
> 
> HTH,
> andrew