Oh, in the proposal as I remember it, the set of card store(s) (as surfaced via IdAS) _is_ the registry. Meaning, we'd use the IdAS registry for registry-like functionality, and IdAS as the way to access cards in their stores.
>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/16/07 5:41 PM >>> I meant that when we create an ICard we'll need to update card store along with ICard Registry within the same transaction.
Tuesday, April 17, 2007, 2:33:31 AM, you wrote:
> > You mean, people will want to update two ICards in two different > card stores within the same transaction? Won't this require each > card store to support some kind of common two-phase commit protocol?
>>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/16/07 4:46 PM >>> > Not too long ago there was a proposal to use IdAS as an ICard > Registry, to my mind, it is one of such use cases.
>> >> >> 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
>>
> _______________________________________________ > higgins-dev mailing list > higgins-dev@xxxxxxxxxxx > https://dev.eclipse.org/mailman/listinfo/higgins-dev
>
|