On Thu, 2001-10-04 at 21:20, Linas Vepstas wrote:
>
> Hi Dave,
>
> Sounds good. I just like to panic when I see 'deep' changes like this.
Ok, cool. I'm glad I wasn't going down a blind alley :)
> > file, otherwise the second session will overwrite all the
> > entries in the global table from the first session.
>
> OK, right. For a moment, I wondered why you'd want to have multiple
> sessions for the same data in the same process, but I can think of one
> good example (which is merging data from two files, that have
> transactions/acounts in common. This can occur in at least several
> scenarios that I can think of.. e.g. importing data from outside
> sources, when the newer import overlaps with an older import.
> Alternately, the 'disconnected operation' scenario, when one looses
> then regains a net connection..)
My specific scenario is that I'd like to open several connections
to the same sql backend and perform updates, making sure they all
stay consistent, as a way of testing the multi-user sql backend.
> > If you want to do a 'save as', where you discard the old
> > session, then you could just move the book and the entity table from
> > the old session to the new one. I intend to make a session
> > function to support that.
>
> OK, yes, that's what I'd want. I'd hate to have to clone a tree just to
> 'save as'.
Yes, right now the gnc-file.c code does some 'tricks' to make that
work. I'd like to move that into the session code to make it cleaner.
> > allows the rpc server to work as
> > intended.
>
> ? I can't imagine why/how ...
As I understand the onc rpc stuff, and Derek can correct me
if I'm wrong, it is set up like this:
Client Engine --------\
Client Engine ------\ \
Client Engine ----- Server Engine
So that multple client engines connect to the server engine,
which in turn has a connect to the 'real' datastore. I may
be wrong in this. But if I'm right, the server engine needs
to have multiple sessions open at once.
> (excuse the following simplisitic language but i wanted to be clear):
>
> What I'd like to call a 'session' is a 'network connectivity session',
> wherein a user or program gets access to a dataset, does stuff, and
> later on finishes up and closes the session. (In the case of a file
> dataset, a session is the case where that file is locked up to prevent
> multiple writers trashing each other: the session object obtains and
> holds the lock).
>
> By contrast, the book (like an account or transaction) is a piece of
> persistent data, that continues to exist even if there are no active
> sessions connected to it.
>
> The gnc_engine is built so that opening a session always causes the
> 'real data' (that lives in a file or db) to be 'cached' locally,
> in RAM, in the engine. The GUI manipulates the cache, and then
> a 'save' causes the 'cache' to be 'flushed' to the 'file' (or
> flushed to the 'server'). In other words, a standard gnc_engine
> 'session' is always associated with the 'local cache' of the data.
>
> And these definitions seem to match what you are building...
Yes, I think so. When I am finished, every book and its associated
objects will need to be associated with some session, but that needn't
be an 'active' session with a backend hooked up. So that sessions are
the separation between independent data sets.
I intend to implement functionality to 'move' data from one
session to another to implement, say, 'save as'.
> ===============================================
> The other way to implement what you wanted would have been to not set
> any guid at all at malloc time; leave the guid to be zero. Later,
> when xaccTransSetGUID is called for the first time, you'd know the
> session, because the guid would already be associated with a session.
> (I guess xaccGUIDMalloc() would need to take a session argument ??)
Yes, that's the other way to do it. It seemed to me that it would be
better to make GUIDs like pointers, and have them be valid all the time,
instead of having them work only sometimes. However, that does require
a few more session arguments.
> ===============================================
> Are you planning on checking for & preventing a 'mix up' objects
> beloning to different sessions? e.g.
> s=xaccMallocSplit(session_a); t=xaccMallocTransaction(session_b);
> xaccInsertSplit (t,s); ?
>
> Is it worth the cpu cycles to do this?
I'm not sure. I was thinking about caching a pointer to the entity
table in the objects to eliminate the need to add session arguments
to a bunch of other functions. This would also make it easy to check
for session mix-up and it wouldn't take very much cpu. In addition, it
would also make it easy to 'move' a book/entity table pair to another
session without changing lots of pointers. That does add an extra data
member to stuff, though. What do you think?
dave
PGP signature
