| Re: [higgins-dev] IdAS update proposals |
|
I added Option 3.a.1 for this >>> "Jim Sermersheim" <jimse@xxxxxxxxxx> 4/16/07 10:35 AM >>> So instead of a TransactionSemantics class which is passed to update operations, we would (optionally) pass an ITransaction instance. This would allow one to build up multiple concurrent transactions (rather than only a single as Option 3.a allows).
In absence of the ITransaction, the update would be applied immediately.
There would be some kind of ITransaction beginTransaction() method, as well as an abortTransaction(ITansaction) and commitTransaction(ITransaction) method.
The ITransaction interface could allow us to specify semantics like "ignore failures" if needed.
Do people want to keep the current update methodology until this can be discussed at the next F2F? Again, we can't write an LDAP CP unless we at least have enough transactional integrity to support making updates to multiple attributes on a single subject at once.
Jim
>>> Michael McIntosh <mikemci@xxxxxxxxxx> 4/16/07 6:28 AM >>> 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 |