Oops, I just noticed you took us off list. Don't do that, others
might have better ideas than me on this.
On Thu, Jul 16, 2009 at 7:59 AM, Anj Adu<fotographs@gmail.com> wrote:
> 1. exec Func A
> 2. call Func B
> 3. Call Func C
>
> Func A is the outermost control function.
> Function B inserts into a set of tables say TableX and TableY
>
> The inserts into TableX and TableY in Function B are needed before FuncC can
> execute. However..if Func C fails..the data in TableX and TableY need not be
> rolled back as they are reference tables. We do not want to repeat the
> inserts into tableX and tableY if the entire process fails downstream for
> some reason.
>
> Currently..I use PL/Java to simulate an autonomous transaction. But it is a
> kludge and PL/Java support for newer JVMs and newer Postgres versions is a
> pain to troubleshoot as support is limited.
>
>
> On Wed, Jul 15, 2009 at 10:59 PM, Scott Marlowe <scott.marlowe@gmail.com>
> wrote:
>>
>> On Wed, Jul 15, 2009 at 10:48 PM, Anj Adu<fotographs@gmail.com> wrote:
>> > We have function A calling function B...then function A goes on to do
>> > other
>> > things (call function C,D)
>> >
>> > The updates/inserts in function B have to be committed for us to achieve
>> > scalability in the process that function A accomplishes (i.e have
>> > multiple
>> > processes calling the A function run in parallel)
>> >
>> > Hence...the question on how to commit.
>>
>> So, are you saying they have to commit, even if they break unique
>> constraints, or FKs and such? Or they have to be skipped? I'm not
>> sure what you're trying to do still. Maybe some pseudo code that lays
>> out what the path is you want to follow on these inserts / updates.
>
>
--
When fascism comes to America, it will be intolerance sold as diversity.