Re[8]: [higgins-dev] IdAS update proposals

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

To my mind, in ICard Registry we have to keep track to rather
each individual card(s) (aka DS) then to card store(s) (aka context).


Tuesday, April 17, 2007, 3:00:16 AM, you wrote:

>  
> 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

>>   


>