Skip to main content

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

What would that look like?  People would call things like addAttribute, etc. and then call update with the list of attributes?  I'm trying to picture the APIs.
Also note that option 1 does specify transaction semantics as it is documented today.

>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/16/07 4:46 PM >>>
I seems to me that current methodology (option 1) extended to keep
track on updates of individual properties and metadatas could be a
good example how to provide transactional support if data store
doesn't support transactions but it is rather choose of implementation
then API.

Valery

Monday, April 16, 2007, 6:57:56 PM, you wrote:



> Well, the way I wrote 3.a, it *is* optional (to the extent that
> it's supported), but it's not separated out into some other interface.



> The problem I see with removing transactional semantics is that
> we're back to option 1 or 2. and we have all the cons listed there.
> People dislike Option 1.  We cannot even write an LDAP provider with
> Option 2 because it doesn't allow us to perform multiple changes at
> once, thus will leave object in invalid states.



> Can someone offer a proposal which allows IdAS to work with LDAP
> directories *and* satisfy everyone in terms of it's lack of transactional semantics?



> Jim



>>>> Greg Byrd <gbyrd@xxxxxxxx> 4/16/07 9:04 AM >>>
> I agree with Mike.   Transactions add a lot of implementation complexity,
> and I thought our previous consensus was that we would not require this
> of all implementations.  If we can somehow separate this into an optional
> capability, that would be good.  (I don't know if Mike meant the optional
> part -- that's just my two cents.)

> ...Greg



> Michael McIntosh 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:
>>
>>  
>>
>> 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