| Re: Re[2]: [higgins-dev] IdAS update proposals |
|
so, Option 3.a allows one to update multiple subjects from a single context in one transaction, but not across contexts.
Are there use-cases for this stuff? I have a real-world use case for the need to lump multiple attribute updates into a single transaction but nothing beyond that. I can see the value in allowing multi-subject transactions, and the value of allowing this across contexts, but less so. I mean, is someone planning on producing context providers that allow two-phase commit? Even an LDAP provider talking to a single server can't support multi-subject transactions unless the backing server has implemented some non-core extension -- let alone transactions across databases.
>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/16/07 10:24 AM >>> I think that we definitely have to consider a case when we need to update multiple subjects perhaps from the different contexts in the same transaction. Valery Monday, April 16, 2007, 3:28:56 PM, you 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: >> I've added more text to Option 3.a. Where do y'all want me to go >> from here? I can start fleshing out the use cases (please tell me >> which ones are of interest to you, and/or add your own). Or I could >> start mocking up the APIs and generate javadoc. >> >> I'd like to get this moving since I'll be gone next Wed-Fri >> >> Jim >> >> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/12/07 4:45 PM >>> >> It's definitely not too early to comment on Option 3.a now. The >> intent should be clear, I could use some help in exploring what >> kinds of problems might arise. >> >> jim >> >> >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/12/07 2:53 PM >>> >> So far, I prefer Option 3.a (I should call it the Daniel options >> since he planted that particular seed) >> >> I'll flesh out the APIs a bit on the wiki >> _______________________________________________ >> 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 _______________________________________________ higgins-dev mailing list higgins-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/higgins-dev |