If we did Option 3.a, we wouldn't need setAutocommit because we would have the TransactionSemantics argument. A user can build and always use a TransactionSemantics which is set to "Immediate". Or am I mis-reading your first sentence?
>>> "Sergey Lyakhov" <slyakhov@xxxxxxxxxxxxxx> 4/16/07 10:36 AM >>>
>I agree with Mike. Transactions add a lot of implementation complexity, > and I thought our previous consensus was that we would not require this > of all implementations. If we can somehow separate this into an optional > capability, that would be good. (I don't know if Mike meant the optional > part -- that's just my two cents.)
We can add setAutocommit(boolean) method to IContext interface with "no transaction support" default mode, so user will be able to reject using of commit() method. In any case the latest update approach (usging UpdateOperation) was defined to support transaction-similar update of DigitalSubject, but it is cumbersome as for user as for context provider. Also it provides transaction-similar update only for one DigitalSubject, so it is not applicable when we want to safely move some attrribute from one Subject to another, for example.
Thanks, Sergey Lyakhov ----- Original Message ----- From: "Greg Byrd" <gbyrd@xxxxxxxx> To: "Higgins (Trust Framework) Project developer discussions" <higgins-dev@xxxxxxxxxxx> Cc: <higgins-dev-bounces@xxxxxxxxxxx> Sent: Monday, April 16, 2007 6:04 PM Subject: Re: [higgins-dev] IdAS update proposals
>I agree with Mike. Transactions add a lot of implementation complexity, > and I thought our previous consensus was that we would not require this > of all implementations. If we can somehow separate this into an optional > capability, that would be good. (I don't know if Mike meant the optional > part -- that's just my two cents.) > > ...Greg > > > > Michael McIntosh wrote: >> On transactions ... >> >> As a general principal, I don't want to pay the overhead of certain >> functionality in Higgins, but I want to make sure its possible/practical >> to add it to derived products. So load balancing/clustering, real audit, >> real access control, real transactions all need to be supportable in >> derived products - but don't need to be fully supported in the reference >> implementation. We do however, need to put the plug points into the >> reference implementation so these enterprise level capabilities can be >> added without modifying existing code. >> In the case of transactions, we'd likely want multiple operations to be >> part of the same transaction. For instance, an update that crosses >> multiple contexts, or one that must be audited should include the commit >> of an associated audit record. >> >> So I think we should consider separating the Transaction into its own >> interface, which can be passed into various update methods. I know this >> introduces a lot of complexity, and I would not want to add it until >> we've discussed it at length (probably a f2f agenda item), but its >> something we need to consider. >> >> Thanks, >> Mike >> >> higgins-dev-bounces@xxxxxxxxxxx wrote on 04/13/2007 07:51:10 PM: >> >> >> https://dev.eclipse.org/mailman/listinfo/higgins-dev >> > > _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev
|