Hey
> On Wed, 27 Sep 2000, Rickard Oberg wrote:
> > It's not a lot of overhead in terms of CPU time (close to zero compared
with
> > the actual JDBC calls), and the tx/non-tx stuff is simply an "if", not
> > different classes.
>
> I thought all JNDI calls involved serialization? But perhaps it
> is small compared to JDBC.
Not following. What does serialization have to do with this?
> In any case, it has to be different classes
> because I have to be able to use Minerva outside J2EE (which means without
> JNDI & JTA, which means different classes).
Some refactoring then. Still, a connection that has been retrieved must be
usable with or without tx, so it's either "no tx" or "no tx or tx".
> We can make everything work *without this*!!! If I just change
> the XAResource so it doesn't complain when you commit/rollback before you
> close, then you will no longer see that exception. Then we comply with
> the spec (subject to my lack of rereading it recently). If we want to go
> further, we allow a connection to be re-attached to a subsequent
> transaction, but I think that is "above and beyond". What you are
> proposing goes even beyond that.
Point taken. Valid, but the underlying connection will be held for more time
than necessary.
> I am not in favor of adding runtime overhead and classes and code
> complexity to support developers using admittedly bad techniques with
> non-spec-compliant database drivers! If you look at our competition, they
> make statements like "you cannot use non-compliant drivers in a two-phase
> commit environment". I don't mind when bad products and bad techniques
> lead to bad performance - I'd rather encourage people to do things right!
Point taken.
Alright, so until we get enough people complaining about "waah, it can't
handle my bad code" we don't do anything. Fair enough ;-)
Topic closed. :-)
regards,
Rickard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
