[Mulgara-dev] XA1 and the String Pool

Pradeep Krishnan pradeepk at soft-point.com
Wed Jul 30 17:16:57 UTC 2008


Hi Paul,

Paul Gearon wrote:
> In the following discussion I'll say "strings", but I really mean
> "strings, URIs, and any other kind of data we store in the string
> pool". Once upon a time we ONLY stored strings. This was because URIs
> are strings (we had a bit to differentiate between URIs and strings),
> and all other data has a lexical form.
> 
> Anyway, saying "strings" makes the conversation easier for me....
>

Sure.


> On Wed, Jul 30, 2008 at 2:03 AM, Pradeep Krishnan
> <pradeepk at soft-point.com> wrote:
>> Paul Gearon wrote:
>>> There are some technical issues to be dealt with, of course. For
>>> instance, if we roll back a transaction, any new entries in the string
>>> pool can be unwound simply by truncating the "packed" data file at the
>>> position of the last commit, and not updating the counter associated
>>> with the node pool. But most of our the operations (and all of the
>>> interfaces) will remain unchanged.
>>>
>> Does this unwind work across a restart after a system crash? ie. when a
>> crash occurs in the middle of a transaction that added entries to the
>> string pool.
> 
> Yes, it will work fine. The "latest" allocated nodes/strings will be
> stored as they always have been. The only consequence would be that
> the flat file containing the new strings would have a lot of "extra"
> stuff at the end that can be discarded. The last commit will hold the
> size of the file (this already happens for several files), so when we
> start up we can see if the file is longer than this "committed" size,
> and if it is then we can truncate the file. This operation already
> occurs for a few different files on startup, so we just do it for the
> new string file.
> 
> With the exception of the new string file, we won't be adding
> anything.... only removing stuff. Everything left will continue to
> operate the same way it always has (an advantage of a modular design),
> so the commit process will be fine there.
> 
>> Also what is the downside of not unwinding on a rollback? Shouldn't the
>> same reasons that support not deleting string pool entries hold here too?
> 
> There's not a lot of downside, and it DID occur to me that we could
> just leave it in. However, even with a write-once system, I feel icky
> allowing a failed transaction to store data for me.  :-)
> 

I was wondering if the recovery depended on the free lists and so a 
substitute mechanism needs to be created. Sound like that isn't the case 
and so I agree with you about the 'icky'-ness :)

Cheers,
Pradeep



More information about the Mulgara-dev mailing list