We have a situation where some java code with jdbc will be calling a
PL/SQL package procedure which does a lot of database updates.
The package will not have any commits in it, so that the java code can
make the call wether to rollback everything the package procedure did
or not. Problem is, the way the procedure was originally coded in
it's exception handler was that if it ran into a problem, it would
rollback itself, and then write an error record to an error table and
then commit. Now we don't want the procedure to rollback or commit
anything, but we need those error codes stored in the database
somehow. So the idea came up an an autonomous transaction procedure
that took the error strings as arguments and committed them to the
database independently of package procedure. But upon thinking about
it more, the autonomous transaction could fail as well, (missing
grant, unable to allocate extent etc.,). meaning that an error code
has to go back to the java code anyhow, leaving me right back where I
started. So now I'm wondering a couple things.. 1) Am I being just a
little too picky? 2) What are these things good for? (autonomous
transactions). Any similar thoughts, experiences or comments?
Right now, I am leaning toward bundling the errors in list object of
some kind and passing it back to the java code so that it can write it
to the database independently. It doesn't seem there would be any
advantage to using the autonomous error writting procedure...
Received on Sat Aug 05 2000 - 00:00:00 CDT
