#4 Use memory database for transacted objects

Transacted objects, like message objects, should store
their data in an in-memory database. This would
greatly boost speed, which is the most important thing.

There was a problem with OpenProperty() and in-memory
database, that's why it was turned off initially. But
that needs to be addressed and turned back on.

[Anonymous]

Logged In: YES
user_id=1456

> I am considered about MEMDB not working
> though. Any idea what the problem was? I
> ran into an issue with MEMDB earlier since
> that MEMDB was attached to the open SQLite
> handle, not the database on disk. That is
> why I converted back to a single SQLite
> handle for the entire service.
>
> Maybe MEMDB is being attached twice? Do you
> remember the issue?

When you call OpenProperty() ordinary property is inserted
to the
MEMDB table with 'Ref' flag set but it is not copied
to desk
table
while SaveChanges(). So after restart store fails to open
message.
Plus OpenProperty for transacted objects should create table
(if it is
table) in MEMDB and copy that table to disk inside
SaveChanges().

[Anonymous]

Logged In: YES
user_id=1456
Originator: YES

REFs to non-transacted objects, eg. table objects already point to the disk database, so that should not cause an issue. The problem with that is that transacted objects that are opened then cancelled will leave empty or nearly empty tables on disk. So these tables need to be created in memory and copied to disk only after the parent object's SaveChanges method is called.

REFs to transacted objects that are saved will also have some problem it seems. These objects would need to have their SaveChanges() method called whenever the parent's SaveChanges() method is called.

REFs to transacted objects from non-transacted objects? Issues?