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

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

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

>