>
> > Therefore, when the transaction is deleted it could call the
> > cdevCallback object with a code in the status word indicating
> > the transaction is completed... i.e. CDEV_END_OF_TRANSACTION.
>
> This could work for multi-part transactions, but is too much overhead
> for single shot cmd/response.
>
> Consider the flow as seen by the user:
>
> Single-shot:
>
> create user object
> create callback object (temporary) pointing to user object
> initiate transaction via device or request objects, which makes
> a copy of the callback object
> delete the callback object (temporary)
> receive callback, delete any user objects no longer needed
>
> Multi-shot:
>
> same as above, except the callback status argument indicates
> wether this is the final callback for this transaction. That is,
> if it is NOT, we introduce a NEW status meaning "partial/ongoing".
> when user gets the FINAL callback, he knows to delete his objects
>
> I prefer this to transfering the "ownership" of the user object to the
> callback object or the transaction. User is responsible for not deleting his
> object until he cancels the transaction.
>
> The difficulty, is that we do not have a general way to cancel transactions,
> because transactions are not visible objects, but rather implementation objects.
> I am not ready to make them visible until someone has a clear need for it,
> because once we make them visible, we can't change their implementation.
>
> Chip
>
I agree that the original idea does generate too much overhead. However,
the developer may still need to know when a transaction that used a
cdevCallback object (perhaps a monitorOn request that has been terminated
with a monitorOff message) is being ended - in order to perform clean-up.
While, this information would certainly be an annoyance on a regular "get"
or "set" request, it becomes quite handy when monitoring.
Would it be reasonable to add two new methods to the cdevCallback class:
void signalEndOfTransaction (int flag = 0 ) { sigEndTrans = flag; }
void signalDeleteCallback (int flag = 0 ) { sigDelCB = flag; }
The transaction object could inspect the sigEndTrans flag and (if
specified) could submit a CDEV_END_OF_TRANSACTION status to the callback
function...
The cdevCallback destructor could inspect the sigDelCB flag and (if
specified) could submit a CDEV_DELETE_CALLBACK status to the callback
function... (*** This would be very useful even in the absense of the
CDEV_END_OF_TRANSACTION message ***).
In either approach, the cdevTranObj still remains hidden while the idea
of "transactions" is made public.
Notably, a service would still have the ability to use a status that
indicated incomplete data, i.e. CDEV_PARTIAL_RESULT when calling the
callback object.
Walt
--
=============================================================
Walt Akers Voice: (757)269-7669 E-Mail: akers@cebaf.gov
Thomas Jefferson National Accelerator Facility
12000 Jefferson Avenue, MS 16A
Newport News, Va 23606
=============================================================