[Mulgara-dev] XA1 and the String Pool

[Paul Gearon]

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....

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.  :-)

Paul