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

[Valery Kokhan <vkokhan@xxxxxxxxxxxxxx>]

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

>