Skip to Main Content
Forums

Integration

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Query on bpel.config.OneWayDelivery Property

user790116Apr 26 2012 — edited Feb 26 2020
Hello,

I have a query on bpel.config.OneWayDelivery Property.

Scenario : In case of any error in BpelProcess A , it will call BpelProcess B .So BpelProcessB will be called in the catchAll branch of Process A. After calling Process B, i am throwing a fault in Process A to rollback process A (as there is a DB adpater in it which i want to roll back). To invoke Process B in a separate transaction i set the bpel.config.transaction to requires new in the component section of composite.xml of process B. Please not Process B is ASynchronous process. Now :

Case 1: By setting only bpel.config.transaction property to 'requiresnew'.

Process A gets error, it calls Process B and it itself get rolledback (because of throw activity after a call to Process B). Now in the instance of Process A i am not able to see the trace of Process B. Only Process B name is appearing, also Process B didn't get executed at all or might be rolledback along with process A (not sure on this).


Case 2: By setting only bpel.config.transaction property to 'requiresnew' and bpel.config.OneWayDelivery property to 'sync'.

In this case everything works fine like Process A call Process B in case of Error. Process A get rolledback successfully and i am able to see the trace of Process B as it get executed successfully.

Questions :

In case1 though i have set the transaction=requiresnew, why Process B is not getting executed and i am not able to see the trace of it.Ideally Process B should get executed in a seperate transaction. While in Case2, everything works fine. So what exactly happening after placing 'OnewayDelivery' Property, that it started working.


I have went through the documents on 'OnewayDelivery', but i didn't get the clear idea corresponding to my scenarios explained above.

Can anyone please explain on how exactly 'OnewayDelivery' property works.

Thanks.
This post has been answered by Arik on Apr 30 2012
Jump to Answer

Comments

Fedor-Oracle
x86_64 Linux system (Gentoo) w/ gcc 4.6.2 and Studio 12.3 (tar).
Sorry, Gentoo is not a supported system (though something might still work).

And gcc 4.6.2 is definitely not supported for -compat=g. Actually anything higher than 4.3 is very likely not to work.
Its headers contain alot of gcc'isms and Studio 12.3 is not able to handle it all.
I do not believe it is possible to workaround these problems.

We gradually move towards being able to work with modern gcc's, but our main target is gcc version installed by default on supported Solarises.
And Solaris is not that quick in adopting latest gcc versions either.
Am I assuming correctly that if I use -compat=g or use stlport4, I cannot make use of the optimized math library that comes with the compiler suite as a replacement for the regular libm
Math stuff is not C++ specific, so it does not matter what -compat mode or STL do you use.
heavy use of the STL and boost. The standard libCstd does not support every feature - which also goes for some of the project's dependencies as well. Is the stlport4 or the native g++ stl the only way to solve this?
We claim support for Boost with -compat=5 -library=stlport4 mode only.
With every compile, I get "CC: Warning: failed to detect system linker version, falling back to custom linker usage".
Old Linux linkers (GNU ld, versions predating 2.20) are not able to properly handle C++ objects generated by Studio.
We ship slightly modified GNU ld which has these problems fixed, for C++ to work on RedHat5/OracleLinux5.
However that custom linker is an old one (version 2.17.90), so it wont work with system libraries on modern Linuxes.
On RH6/OL6 we were able to force system linker (2.20) to work properly.
Hence CC tries to detect system linker version and apply a workaround.
It seems that your system linker has --version output that CC cant match, so it runs old linker shipped with Studio.
Its not going to do anything good :(
I have a small test program which basically is a loop that iterates UINT32_MAX times and does some calculation. I use OpenMP's parallel for without any hint to scheduling, number of threads or such. All compilers (g++, icc, path64) I tried, correctly put out 8 threads to handle the load. Except for the version compiled with solaris studio compiler. It only launched two threads and came in last. After manually forcing it to 8 threads (OMP_NUM_THREADS=8), it worked like a charm and even took the lead. Again, it is a simple and stupid test. But I wonder what I am missing because it should not be the user's job to set the right number of thread for his machine.
Wonder what kind of hardware do you have?
Starting number of threads is a "static" decision performed by OpenMP runtime at the start of the paralllel region and is implementation-defined (thus any choice is ok wrt OpenMP standard).
I dont remember whats our heuristics for this decision is right away, but it should be something proportional to the number of CPUs.
It is nearly impossible to make an efficient decision for every program/hardware combo.
Either our heuristics happens to not match your test program, or the runtime fails to detect the number of CPUs on your system.

regards,
__Fedor.

Edited by: SFV on Feb 24, 2012 4:22 PM
919808
Sorry, Gentoo is not a supported system (though something might still work).
I know. That goes for most software, actually... and one gets used to it, if you do not use one of the major distros. But on the other hand, it rarely causes any problems that cannot be solved.
And gcc 4.6.2 is definitely not supported for -compat=g. [...]
Ah, okay. Thanks for that information. That explains a lot and I will stay clear of it in the future until I read otherwise in the release logs. :)
Math stuff is not C++ specific, so it does not matter what -compat mode or STL do you use.
At least that door for a good speed up is still open. Nice to hear.
We claim support for Boost with -compat=5 -library=stlport4 mode only.
-library=stlport4 implies -compat=5, if I am not mistaken? Or -compat=5 is the default anyways. I remember having read something about it.
It seems that your system linker has --version output that CC cant match, so it runs old linker shipped with Studio.
Its not going to do anything good :(
Is there any way I can workaround that or force the compiler to use my linker nevertheless?
Wonder what kind of hardware do you have?
Core i7 860 (4 real cores + 4 HT).
Either our heuristics happens to not match your test program, or the runtime fails to detect the number of CPUs on your system.
I would guess it is most likely the latter. Is there any way I can force debug information about this?

Thanks for your swift answer by the way, it is very much appreciated.

So long
matthias
Fedor-Oracle
-library=stlport4 implies -compat=5,
Yes, that was somewhat ambiguous.
We claim the support for Boost with -library=stlport4 only.

You might get a reasonable set of Boost libraries working fine with -compat=g. But then again, -compat=g does not work for you..
Is there any way I can workaround that or force the compiler to use my linker nevertheless?
I cant see non-cumbersome workarounds currently. Will get back to it later.

regards,
__Fedor.
919808
I cant see non-cumbersome workarounds currently. Will get back to it later.
For now, I've replaced the bundled "ld" with a symlink to the system one. :)

By the way, doing a strace revealed nothing interesting. 27796 was the pid of the system ld which simply processed the version option. But still, you can see the version string which maybe not quite to the liking of suncc:

<... setregid resumed> ) = 27796
--- {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=27796, si_status=0, si_utime=0, si_stime=0} (Child exited) ---
[ Process PID=27791 runs in 32 bit mode. ]
open("/tmp/gnuld_version.1330099288.27791.03", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=266, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xfffffffff718f000
read(3, "GNU ld (GNU Binutils) 2.22\nCopyr"..., 4096) = 266
read(3, "", 4096) = 0
write(2, "CC: Warning: ", 13CC: Warning: ) = 13
write(2, "failed to detect system linker v"..., 76failed to detect system linker version, falling back to custom linker usage
) = 76

Hope that helps.

Thanks again for your help.

So long,
matthias
974389
khaos wrote:
write(2, "failed to detect system linker v"..., 76failed to detect system linker version, falling back to custom linker usage
A hack (and it's just that) is to edit bfd/configure, changing PKGVERSION="(GNU binutils) " to "*PKGVERSION="version "*. That changes the version text from GNU ld (GNU Binutils) 2.23 to simply GNU ld version 2.23 which is recognized by CC as a valid version string. Rebulld and install that modified version of the binutils package.

Edited by: user1398506 on Nov 15, 2012 1:03 AM
Fedor-Oracle
That changes the version text from GNU ld (GNU Binutils) 2.23 to simply GNU ld version 2.23 which is recognized by CC
Indeed, CC matches version text with "GNU ld version" string. This is what linker on our supported platforms reports.

A good news is that we might drop shipping modified linker (and thus there will be no need for linker detection) in a future release.

regards,
__Fedor.
Steve.Clamage-Oracle
[posted by mistake]
1 - 7
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on May 30 2012
Added on Apr 26 2012
#11g, #bpel, #business-process-management-suite, #soa-process-management, #weblogic
6 comments
339 views