Jim Starkey wrote:

>
> At 03:18 PM 5/31/00 -0700, Brett Bandy wrote:
> >
> >Jim Starkey wrote:
> >>
> >> Like Jdbc, there is not explicit support for multiple transactions
> >> per process. To get them, multiple attachments are required. There
> >> is a temptation to add a clone() method to Connection simplify the
> >> coding and allow sharing is the InterBase database attachment.
> >
> >How do you set a transaction's attributes? (ie wait vs nowait, ...)
> >
> virtual void setAutoCommit (bool setting) = 0;
> virtual bool getAutoCommit() = 0;
> virtual void setTransactionIsolation (int level) = 0;
> virtual int getTransactionIsolation() = 0;
>
> (OK, I did forget them. I don't approve of autocommit and left
> it out of Netfrastructure from which I swiped the code. It's
> now in).
>
> >Is the default trans mode autocommit :)
> >
>
> JDBC says default is auto commit. So be it. Yuckola.

I'm all for complying with JDBC as well, but I think that maybe we
should rethink the autocommit thing. I can't tell you how many
performance issues I've dealt with where the developer either chose
autocommit or didn't even know that transactions existed. Autocommit
allows these developers to get away with their old (maybe paradox-like)
programming habits only to bit them in the &^$ when they deploy their
app to a concurrent, non-local environment.

>
> >Since InterBase supports multiple transactions against a single database
> >as well as a single trans against multiple databases, was there thought
> >given to creating a transaction class?
> >
>
> Yes, but I though following the standard was more important.
> Connection::clone() will accomplish almost the same thing. Actually,
> in my implementation, it will accompish exactly the same thing.
>
> I'm going to think about the multi-database commit until after I
> get something out. I don't think an InterBase only solution is
> worth the trouble. I need to re-examine XA and Microsoft's transaction
> controller before I propose something.
>
> >>
> >> resultSet->release();
> >> statement->release();
> >> connection->close();
> >
> >Could you explain the difference between release and close?
> >
>
> Objects have use counts, born at 1, incremented by addRef() and
> decremented by release(). When the use count goes to zero, the
> object disappears (with appropriate cleanup). Like COM, the
> idea is that everyone who copies a pointer initially calls addRef()
> then release() when he's done with it. JDBC doesn't need to track
> object life times, hence doesn't need addRef/release, and uses
> close() to dissociate resources held by an object. I've kept
> close() for compatibility (perhap a bad idea?). Close() overrides
> the use count and deletes the object forthwith and directly. I'm
> not happy with the overlapping mechanisms. What do you think?

Ahh, I understand. With the explanation you've given I'm in favor of
dropping close. If they developed their app correctly they should have
a matching call to release for every reference that is created, correct?

Is there a case where they would want to close() the object? maybe a
network error was received? maybe their app received a shutdown signal
or message?

Brett