[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re[2]: [higgins-dev] IdAS update proposals
|
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