Re: Re[2]: [higgins-dev] IdAS update proposals (Transactional support)

["Tom Doman" <TDoman@xxxxxxxxxx>]

Thor,

Yes, that's precisely the problem.  The internal service that updates
the LDAP is bound by the transactional semantics of LDAP.  LDAP allows
updates to one and only one "entry" (roughly a DS) at a time.  I'd expect
any implementation with LDAP that tried to emulate a single transaction
over multiple DS modifications to quickly become a house of cards.  I'm
still thinking it through but I'm not sure it wouldn't be absolutely impossible
especially in light of the fact that there is nothing a CP writer can do to
control all transactions happening through other modifiers of the LDAP
that aren't going through the CP.  The CP would not be able to know
for sure what changes to rollback nor whether an attempted rollback
would leave the object in a consistent state.  If not simply from the LDAP
perspective (meaning the rollback modification would result in an LDAP
failure while we're trying to recover from the original failure) but perhaps
from the application perspective which are sharing the objects in
simultaneous modification. 

Tom

>>> "Thor Wolpert" <thor@xxxxxxxxxx> 4/17/2007 6:04 PM >>>
Yes, when I'm directly dealing with the LDAP interface, but if I'm dealing
with a service in front of the LDAP interface I could hand off all of those
items as one call.  The internal service that updates the LDAP could go
through any series of steps required.  Unless I'm missing something in that
behind the scenes you want a way to have 2-phase commit across a series of
internal services ... which will be an ordering and problematic environment
if not all sub-components support it.  If only some sub-components support
it, then you'll end up with a transaction in-doubt and have no real way to
recover.

Thor HW


On 4/17/07, Jim Sermersheim <jimse@xxxxxxxxxx> wrote:
>
>  Some CP's cannot actually perform some operations against the backing
> data until others have been performed.  For example, an LDAP provider cannot
> create any subject, and then start adding attributes to it.  This is because
> certain subject types have mandatory attributes.  Thus we need some way of
> saying: Create a subject (but not quite yet), add these attributes (but not
> quite yet), add these value to those attributes (but not quite yet), then
> finally, yes--do it.
>
> Jim
>
> >>> "Thor Wolpert" <thor@xxxxxxxxxx> 4/17/07 4:12 PM >>>
> Why not leave all of the actions as atomic at the aggregate level?  If not
> you'll need to set timeout levels and what actions to take in a timeout, as
> this is a distributed systems setup.
>
>
> On 4/17/07, Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> wrote:
> >
> > On Transactions.
> >
> > I was trying to imagine how such stuff could be implemented and how it
> > will work all together but actually failed.
> > For what purposes we may need concurrent transactions?
> > What is the purpose of ITransaction parameter passed to
> > update operation?
> >
> > It seems to me that it is better to keep things as simple as
> > possible.
> >
> > Why not just define something very simple like:
> >
> > interface ITransaction {
> > void begin();
> > void commit() throws SomeException;
> > void rollback();
> > }
> >
> > interface IContext {
> > // Returns single transaction object associated with the context if
> > // any
> > ITransaction getTransaction();
> > ...
> > }
> >
> > In such case if:
> > 1. CP doesn't support transactions getTransaction just returns null
> > and all update operations are immediate;
> > 2. CP does support transactions all update operations after begin()
> > are held until either commit() or rollback().
> >
> > Such approach, to my mind, is simple enough to implement and clear
> > enough to use.
> >
> >
> > Valery
> >
> > Tuesday, April 17, 2007, 1:35:09 AM, you wrote:
> >
> > >
> > > 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 
> >
> > >
> >
> > _______________________________________________
> > higgins-dev mailing list
> > higgins-dev@xxxxxxxxxxx 
> > https://dev.eclipse.org/mailman/listinfo/higgins-dev 
> >
>
>
>