> >> 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.

It would probably be Ok.

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

I think this could be a good compromise. Right off I can't think of a
problem for this except for the focused dataset stuff. As far as
database/driver session linkage is concerned though, there is no problem.

What I would like is to figure out a way to separate the raw database stuff
from the GUI stuff. That would be a pretty heavy re-write and I'll save that
for EDO. Any thoughts you want to share on that would be welcome.

> >> 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
> clean things up when the session and/or the connection are changed.

This probably would do it. I support such a change in IBO. It should also be
able to be transparent. Thus, things would look the same as they do now
except that the IB_Session property of the TIB_Connection component would be
published and writable. I like this. Then, the other components won'
participate with a session until they get a connection reference.

Now, how do you handle a transaction component that is connected to
different connections? I think some kind of convention that the transaction
will use the session for the first connection in its list.

> 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.

Yes.

> 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.

That's exciting. I have taken stabs at doing this in the past and it was
monitoring that shut some of my ideas down. if something is going to need
more major work, I'd rather it be the monitoring part. Looking forward to
seeing what you have. From the sounds of it, there shouldn't be a tremendous
amount of source changes.

Jason Wharton
www.ibobjects.com