Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: Re[6]: [higgins-dev] IdAS update proposals

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

>  


Back to the top