On 2002.05.21 14:41:56 -0400 rrokytskyy wrote:

> Hi,
>
> > The piece we need to complete the puzzle is a thin JDBC-2 compliant
> > driver (preferable type 4) with minimal footprint. The current JDBC
> > type 4 driver is sub-optimal in our case because it includes many
> > feature we don't use (XA, JCA, pooling, log4j).
> >
> > It'd be nice if the current client-java were refactored to be
> > modular, where there's a firebirdsql-jdbc2.jar (or whatever)
> > providing nothing more than jdbc2.
>
> I'm afraid this is not possible at present time. JCA functionality is
> the bottom-most level of the driver, and I'm afraid that refactoring
> would need to much efforts to make a clean separation between JCA and
> JDBC.
>
> What I do not understand, is why you are opposing current driver
> architecture? Main inconvinience is that you need to include some
> additional jars in classpath. JCA level does not introduce any
> overhead (only if you consider one additional method call as
> overhead). From the point of view of JDBC implementation, JCA classes
> are just factories for low-level database connection handles,
> transaction handles and statement handles.
>
> > the one and only selling point for us is that it provides JDBC
> > connectivity to firebird, and does so in a way we prefer to
> > InterClient.
>
> I agree. This is JDBC driver, not JCA reference implementation. But
> JDBC compliance has nothing to do with JCA. We have not disabled any
> feature except efficient autocommit for sake of JCA compatibility.
> Autocommit case is very specific and personally I have no idea how to
> solve it at all.
>
> > I think there's quite a few "buyers" that like it for other
> > reasons.
>
> Well, the one clear thing is that InterBase supports native 2PC (two-
> phase commit), standard JDBC is 1PC, XA is 2PC. So, in case of
> transaction management, JCA fits better. You always can map 2PC into
> 1PC by merging prepare and commit phases. Reverse mapping is not so
> easy (BTW, does anybody know how JCA wrappers solve this issue?).

Unlike the j2ee idea of jdbc support, jca has the notion of
LocalTransactions, which are 1pc. Adapters can have one of 3 levels of tx
support: xa, local, or none. The LocalTransaction implementation is my
preferred way of avoiding 2pc when it is known not to be needed, since you
tell the adapter explicitly when you want the tx to start, and you don't
need to set autocommit. If there is no current tx, you get autocommit.

Application servers are required to be able to use their tx manager to
manage LocalTransactions on adapters with only LocalTransaction support.
Of course, you don't get xa semantics, so it's really only appropriate if
you have only one resource manager [database].

There are at least 8 easy to think of levels of tx support, and jca
supports only 2. (leaving "no tx" out of both counts).

>
> > summary: I don't want to critize, just convince of need. A slim
> > jdbc2-compliant type 4 driver for firebird would be useful in many
> > cases, both OSS (majority of jakarta/xml @ apache) and custom
> > shop.
>
> Maybe the key issue here is "slim". Our driver is not slim. In my
> opinion "slim" driver is only needed when you download classes over
> the network (JDBC in applet), but that's quite rare case nowadays. If
> you are on the server side, you do not really care how big is driver,
> only how fast is it. And in my opinion this is direction to go.

I agree.

So far I haven't seen any arguments that make me think that adding more
packages is a plausible idea. It is certainly possible, but I haven't seen
any benefits mentioned. I still think merging the jca and jdbc packages
would have quite a few design benefits, many of them noted in the source as
"This method should be package visibility".

david

>
> Best regards,
> Roman Rokytskyy
>
>
>
> To unsubscribe from this group, send an email to:
> Firebird-Java-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>