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

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