Jason,

J> Thanks for shedding light on this important area and sorry I didn't respond
J> more promptly. The rollout I've been working on has really been a time
J> miser...

I knew it. Thank you for the useful thoughts.

>> 1- The IB_Session property of IB_Connection and IB_Transaction can only
>> be set by code, not at design time.

J> This is a current limitation, yes.

Do you anticipate any problems if I make it published?
I don't think it would cause any harm.

>> 2- The IB_Session of IBODataSet is read-only.
>> InternalDataSet.IB_Session can be set by code, but internal
>> IB_Statement objects created for fetches, lookups, etc. invariably get
>> bound to a "default" IB_Session, thus defeating the assignment and
>> generating all kinds of interesting effects.

J> This also is currently a potential problem.

Actually I don't think the IB_Session should be assigned to datasets
at all (so I believe that TIBODataset's behaviour is more correct than
TIB_Dataset's). The dataset should always use it's connection's
IB_Session. Something along the lines of:

if Assigned(IB_Connection) then
IB_Session = IB_Connection.IB_Session
else
IB_Session = FindSession and the current algorithm...

As a consequence, changing the value of IB_Session for a connection
component should reflect to all datasets linked to it.

Do you agree?

>> 3- Once a IB_Session component is put on a form, it becomes the
>> "default" session for all IB_Components on that form. All other
>> IB_Session components are ignored unless I use them in code, which
>> takes me back to point 2.

J> I believe this is correct.

Yep. This is useful but a little obscure at design time since the
IB_Session property is not visible. If the changes outlined above are
applied, I think this auto-session feature can be kept as it stays
useful. Other component suites do auto-linkng of components when they
are dropped on a form.

>> 4- The components apparently don't check session coherence. IOW, I can
>> have the usual IB_Connection, IB_Transaction and IB_Query bunch, link
>> them together and link each of these to a different IB_Session without
>> getting errors until late in the form of strange effects, assertions
>> and AVs in the client library.

J> It is true that session management in IBO is not so flexible because I have
J> had the luxury of a single DLL file to attach to. Now that we are having
J> multiple clients to potentially connect to it makes good sense to bring the
J> TIB_Session referencing system up to date with full flexibility both at
J> design-time and at run-time.

I believe this limitation can be overcome if we make it so that a
dataset's IB_Session is always that of the associated connection, as
explained above. The problem I would personally find in doing it is to
clan things up when the session and/or the connection are changed.

J> I envision being able to drop multiple session components onto a form and be
J> able to hook them up at will.

Then we're on the same line.

J> The alternative that I am still pondering on the benefits of, would be to
J> keep the monolythic TIB_Session scheme as it is and enable it to broker
J> between the various client interfaces. Then, there would be a driver-like
J> setting configured at the connection level.

I'm not sure I fully understand, but it looks like the way I tried
first and unfortunately it didn't fly (see the private e-mail I sent
you some days ago).

J> There is actually quite a bit of differences between the old BDE session
J> stuff and the IBO session stuff. My goal was to try and simplify session
J> management and make it able to drop into the background as much as possible.

Understood.

J> Case 1: Gui application with no multi-threading. Didn't want anyone to have
J> to do anything with the session. Introduced TIB_SessionProps to get at the
J> default session's properties. Was nothing more than a way to supply those
J> values at design-time.

This mode would be preserved with the changes outlined above.

J> Case 2: Multi-threaded application that uses datamodules or webmodules, etc.
J> Drop a TIB_Session component on it and make it first and then have
J> everything else automatically hook up to it as its session. Kind of like an
J> automatic homing device.

This would be preserved too.

J> Case 3: No particular modules or application style. Everything in code. In
J> this case I use the Ownership chain as the path to session resolution. Each
J> time something is created it is sensitive to what thread it is involved
J> with. Thus, right at the time of creation the session referencing is
J> immediately important. Thus, it made sense to me to have the object creation
J> scheme be coupled with the session referencing scheme.

This one too, even though I'm not sure it's a common situation.

Case 4: An application like that of Case 1, but with the need to
access multiple databases possibly using multiple client library
instances. In such applications, data access components can be
"reused" with different IB_Sessions, that is I can use a query
component on a remote IB database, then later link it with another
IB_Session component and do the same query to a Firebird embedded
database. This doesn't look a common situation either, but I happened
to need it some time ago. Now I'm in a much better position as I don't
need the multiple clients anymore, but work started must be finished.
:-)

J> The blind spot is if someone doesn't know to use the above conventions (IOW,
J> they didn't read documentation) they may assume it is save to create objects
J> with a NIL owner. IN IBO this could be a potential source of problems if you
J> have nil owner objects that are tied to the default session being used from
J> multi-threading environs.

I think objects without owners shouldn't get a session reference
unless they are linked to a connection. But since currently IBO
assumes the IB_Session is *always* assigned (otherwise, based on a
compiler define, it throws an exception), changing this assumption
would result in an endless chain of AVs in both the components and the
applications. It is not desirable.

J> I am very much open to suggestions and additional cases I perhaps didn't
J> think of that I should have. I am also keenly interested in how people would
J> like to see these new client API's to be simultaneously attached to in one
J> application and potentially even switched on a single run-time session.

I am interested too, since I am building it. :-)
If you agree with the changes outlined at the beginning of this
messages, I'll put them in too and then send you the modified sources. I
am working based on IBO 4.3Aa.

I'm gonna need your assistence on a couple of thing I have broken
(like monitorning and connection pooling, just peanuts! ;-)) but the
work is almost finished.

Ciao
--
Nando mailto:nandod@...