I don't think Oracle has necessarily implemented it in a
non-professional way. It's just that the DBs get so damn big! When you
start taking about dozens or hundreds of users with dozens or hundreds of
tables and corresponding other DB objects - well, it just takes a long
time to load it all, or transfer it over the network, or whatever.
How does the transaction get marked for rollback? I don't see the
code that does that - we handle the SQLException directly from the
PreparedStatement, so what can intervene to mark the transaction for
rollback? Only Minerva, I would think, but I don't believe it does.
Regardless of what the spec says, I don't think DatabaseMetaData
is the right solution. Let's try to avoid marking it for rollback, and
then we should be fine.
Aaron
On Wed, 11 Oct 2000, Daniel Schulze wrote:
> I dont have Oracle so I dont know these Problems ;-)))
>
> No, I didnt know that. The Problem was that the wired query in case of
> table does not exist caused a SQL error, which killed my transaction
> (marked rollback).
> Two possible ways to solve it:
> 1. bring the transaction stuff into the jaws code and use two
> transactions for this operation (reuse the old code)
>
> 2. Use a general way to obtain the databases metadata and make a
> decission bases on that. The j2ee spec (v1.3 section 9.2.2.3) says that
> a compatible driver has to implement that, so I thought Oracle does it
> in an professional way.
>
> Any ideas appreciated.
>
> regards
> Daniel
>
>
