Forum Stats

  • 3,837,690 Users
  • 2,262,286 Discussions
  • 7,900,363 Comments

Discussions

DbAdapter : force commit ?

mathieu.d
mathieu.d Member Posts: 112
edited Jun 6, 2013 10:23AM in SOA Suite Discusssions
Hello,

Is it possible, in an asynchronous BPEL process, to explicitely force the commit of a DbAdapter "merge" operation without waiting for the global transaction to commit ?

regards,
mathieu
Tagged:

Answers

  • Abhinav
    Abhinav Member Posts: 288
    Mathieu,

    Insert a Dehydration point from the Oracle Extensions as the last activity..

    Regards,
    Abhinav Gupta
    Abhinav
  • mathieu.d
    mathieu.d Member Posts: 112
    Thanks for the tips.
    I do agree that this will make the DbAdapter to commit because it will commit the global transaction. But since it will commit the global transaction, all the other activites that should not be commited will also be.

    What I want is to make the DbAdapter outside of the transaction. (And if possible without exporting it in a sub BPEL process having its own transaction)
    Isn't there any setting / properties for this ?

    regards,
    mathieu
  • Abhinav
    Abhinav Member Posts: 288
    edited Jun 5, 2013 7:10AM
    Mathieu,

    2459868
    The important fact is that BPEL will be always in a transaction... Apparently your adapter is participation in the BPEL JTA transaction (rather than creating a new one)... Thus, when trying to send a local commit, it will fail because "This ManagedConnection is managed by container for its transactional behavior and has been enlisted to JTA transaction by container"...
    So you got to see what's better for your case, participate on BPEL transaction and let BPEL commit the transaction for you or somehow put your JCA adapter in a transaction context different than the BPEL one..
    Hope it helps ...

    Regards,
    Abhinav Gupta
  • mathieu.d
    mathieu.d Member Posts: 112
    edited Jun 5, 2013 7:58AM
    So you got to see what's better for your case, participate on BPEL transaction and let BPEL commit the transaction for you or somehow put your JCA adapter in a transaction context different than the BPEL one..
    Well, that's definetly what I'm trying to do. But so far, I can't find how (apart from the solution I gave above).

    regards,
    mathieu
  • May be you should use non-xa connection pool for this DBAdapter?
    samolisov-JavaNet
  • mathieu.d
    mathieu.d Member Posts: 112
    edited Jun 6, 2013 5:27AM
    Thx,

    I'll investigate in that direction.
  • user100012345
    user100012345 Member Posts: 171
    Try using non-xa datasource and use the commit in your pl/sql code.

    This is what we have done when we call ebs pacakges from soa.

    However if you have to implement rollback for db adapter in soa then non xa is a bad choice
  • mathieu.d
    mathieu.d Member Posts: 112
    edited Jun 6, 2013 10:23AM
    Try using non-xa datasource and use the commit in your pl/sql code.
    I don't have control over the PL/SQL code because I use the predefined "merge" operation of the DbAdapter. I'm not using pure SQL or a stored procedure.
    However if you have to implement rollback for db adapter in soa then non xa is a bad choice
    Sure. But in this particular case I do want to commit the change just after the operation, so there is no rollback to manage.

    Thanks for your inputs.

    regards,
    mathieu
This discussion has been closed.