GnuCash Daily Source Diff

[Linas Vepstas]

On Thu, Oct 04, 2001 at 09:48:01PM -0700, Dave Peticolas was heard to remark:
> 
> 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.

I feel like the nervous student, waiting for the exam grade to 
come in ...


[..RPC..]
> 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.

Hmm.  Dunno. Never been there.  I can imagine multiple rpc servers.  
But I can't imagine why one would need more than one session if all
the clients are connecting to the same (single-threaded) process.

That is, assuming they're all reading the same book .. hmmm ...
OK, I admit, if there is one server serving up multiple books,
then you'd need that ... yep, that's it ...

> > ===============================================
> > 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?

sounds good.  Functions should have a small number of arguments.  
Having too many arguments just makes it harder for the api user to
understand ... leading to more cheap hacks, shortcuts and mistakes.

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
     Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933