|
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
|
