Results 1 to 6 of 6

Thread: Journal File

  1. #1

    Default Journal File

    I have read the website and documentation. I don't see a mention of a journal file for STSdb 4.x.

    Does it have one? If no:
    1. What is the philosophy of data protection between commits?
    If yes:
    1. Can one specify which disk is used?
    Finally, what is the philosophy of data commits? I know the less often, the better for speed and DB size.

  2. #2

    Default

    Quote Originally Posted by IanC View Post
    I have read the website and documentation. I don't see a mention of a journal file for STSdb 4.x.

    Does it have one? If no:

    1. What is the philosophy of data protection between commits?
    Greetings Ian.

    STSdb 4.0 does not have a separate journal file. It uses only one file in which the system information and data are stored.

    As you know from the documentation, the STSdb storage engine works with a IHeap implementation which is responsible for managing database space – space allocation, deallocation etc. The current Heap implementation guarantees data protection only if a Commit is succesfull - the data integrity between two Commit operations is not guaranteed, unless the second commit is succesfull.

    If the Commit is succesfull, it "stamps" the changes in the file and guarantees that if a crash occurs, the database can be loaded from the last sucesfull commit state.

    Quote Originally Posted by IanC View Post
    Finally, what is the philosophy of data commits? I know the less often, the better for speed and DB size.
    The philosophy of data commits is explained in the following thread: Recommend Commit Time. The general idea is that Commit operations must be reduced to some minimum amount that will not hurt the overall performance.
    Last edited by p.petkov; 04.12.2014 at 15:21.

  3. #3

    Default

    Greetings Christian

    I hope I guessed your name correctly.

    OK, I understand. Are there plans to include a journal file? This would align with your mission statement, provide the "save and forget" we love about most databases, enable you to develop internal algorithms that decide when best to Commit(), and ultimately improve performance (not to mention endurance).

    This feature would take the product to a whole new level.

    If the journal were configurable, the developer could assign it to a separate disk device, which would mitigate its overhead. Data could be serialized into the journal using IData, and moved already serialized to the IHeap.

    Just some ideas.

  4. #4

    Default

    Thank you for your ideas.

    We are preparing an improved indexing technology and new features for the next major release of STSdb.

  5. #5

    Default

    I look forward to the next release.

    I would like to use STSdb in my upcoming projects (which are considerable in scope), but unfortunately I require a few more features before I can do so.

    Is there any way you could let me know (perhaps privately) when the release is planned for and what the features will be? I know you guys keep your roadmap confidential.

  6. #6

    Default

    Quote Originally Posted by IanC View Post
    I look forward to the next release.

    I would like to use STSdb in my upcoming projects (which are considerable in scope), but unfortunately I require a few more features before I can do so.

    Is there any way you could let me know (perhaps privately) when the release is planned for and what the features will be? I know you guys keep your roadmap confidential.
    Greetings Ian.

    The next release will feature a new indexing technology, ACID transactions on per table level as well as faster Commit and more. At this time we can't say a specific date for the next release.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
2002 - 2014 STS Soft SC. All Rights reserved.
STSdb, Waterfall Tree and WTree are registered trademarks of STS Soft SC.