Why prevent call-ins from within transaction?

S. Rigaud
  • S. Rigaud

    S. Rigaud - 2009-03-09


    I read the following in the doc.: "GT.M currently does not handle
    TP support across multiple call-in invocations. Make sure all
    external call C functions, that invoke call-in functionality are not
    fenced within a TSTART/TCOMMIT boundary"...

    Can someone tell me why there is no transactional support through
    call-in interface ?

    Any way to get around this issue ?


    • Narayanan S Rajamani


      Just to be sure, transactions ARE supported with the call-in interface in the usual case. It is only multiple call-ins that are not supported.

      The rule is that call-ins are not allowed if you are already in a TSTART transaction.

      Examples that are supported

      1) main.m has not done TSTART and invokes callout.c which in turn invokes callin.m that does TSTART/TCOMMIT.

      2) main.m has done a TSTART but before doing a TCOMMIT it invokes callout.c that does NOT do any call-ins.

      Example that is NOT supported

      1) main.m has done a TSTART and before doing a TCOMMIT it invokes callout.c which in turn invokes callin.m (i.e. does call-ins).

      The reason why this is not supported is that in case the transaction needs to be rolled-back/restarted while it is in callin.m, in addition to rolling back all M activity in callin.m and main.m (until the TSTART) GT.M also has to roll back the C stack corresponding to callout.c and then reexecute it all (in case of a restart) which might cause undesirable effects (like memory and file descriptor leaks etc.) in case callout.c was not coded to be reexecutable. GT.M has no control of the C environment which is why it simply does not support it.

      Do you have an example scenario that falls under the NOT supported category?



Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks