Hi Danesh, I also think #4 is proper. This is the way we track transaction commit/rollback status as well, so if you take a look @ the semantics of commit, this should be similar. So, ideally every supposedly unit operation, which happens to invoke other operations will increment the counter before invoking the subsequent operation and decrement the counter after it completes. This approach however, needs to be done @ every handler, component, kernel etc.
Suggestion 05: Another trick though I'm not sure about the possibility is to track the transaction depth counter. This counter too will have information as to how far deep you are inside a transaction. Which is similar to the counter you are talking about. One catch is that the mount handler pushes this counter into a stack when it goes into a JDBC mount to make it possible to have transactions across DBs. To handle this AFAIU, you can also check whether the mount handler's stack is empty or not. But, I don't see it to be good idea to have this accessed outside of the kernel, so may be introduce a method inside the Transaction API of the kernel to explain whether you are within the terminal operation of a nested query or whether you are infact inside a nested operation. Thanks, Senaka. On Mon, Aug 18, 2014 at 8:05 PM, Danesh Kuruppu <dan...@wso2.com> wrote: > Hi Senaka, > Earlier we had an idea of having a flag and problem was how we could > handle the flag inside multiple request. > Suggestions we had earlier, > > Suggestion 01: Keep a flag in requestContext to track event firing. > *This is impossible because inside one request, there are multiple > requests and each request trigger eventing handler.* > > Suggestion 02: Keep a ThreadLocal flag to track event firing. > *Problem with this is we couldn't clearing identify the boundaries of one > user request. We need to put the flag down at the end of the request which > we couldn't find easily. * > > Suggestion 03: Keep a flag in requestContext and whenever new request > create inside the main request, transfer the flag status of the previous > request to the new request. transferor is a threadlocal variable. Here each > time we invoke registry call, we set the value of the threadlocal variable > to the current flag status of the requestContext and inside registry call > we set the flag value of the new requestContext to the value in threadLocal > variable. > > *This is too complex solution. we need to find out all registry call and > set the variable manually.* > Suggestion 04 : Keep a threadLocal stack to track the request flow. Here > each time we create request, we put it in the stack and at the end of the > registry call we remove that request from the stack. typical request flow > e.g.: > > Put | Add Request >> Stack Size >> 1 >> Put | Add Request >> Stack Size >> 2 >> Remove Association | Add Request >> Stack Size >> 3 >> Remove Association | Remove Request >> Stack Size >> 3 >> Remove Association | Add Request >> Stack Size >> 3 >> Put | Add Request >> Stack Size >> 4 >> Put | Remove Request >> Stack Size >> 4 >> Remove Association | Remove Request >> Stack Size >> 3 >> Put | Add Request >> Stack Size >> 3 >> Put | Remove Request >> Stack Size >> 3 >> Add Association | Add Request >> Stack Size >> 3 >> Add Association | Remove Request >> Stack Size >> 3 >> Put | Remove Request >> Stack Size >> 2 >> Put | Remove Request >> Stack Size >> 1 >> > > the Stack size reach the zero means we are at the end of the user request. > we can trigger eventing handler to generate notification. > *Currently this works for me, but don't know whether this is a feasible > solution.* > > Thanks > > > On Mon, Aug 18, 2014 at 6:25 PM, Senaka Fernando <sen...@wso2.com> wrote: > >> Hi Eranda, >> >> Alright. So, just stop the duplication. Ideally, the handler should only >> be triggered once. And, AFAIU, this is doable with the association-update >> and recursive delete handlers (and other utility handlers of similar sort) >> can set some flag within themselves preventing the eventing handlers from >> firing events for those. Won't this work? >> >> Thanks, >> Senaka. >> >> >> On Mon, Aug 18, 2014 at 1:42 PM, Eranda Sooriyabandara <era...@wso2.com> >> wrote: >> >>> Hi Senaka, >>> Requirement here is that when we do a artifact update the subscriber >>> getting massive number of mails saying resource updated where the number >>> depends on the number of associations and properties/hidden properties. >>> >>> thanks >>> Eranda >>> >>> >>> On Mon, Aug 18, 2014 at 6:02 PM, Senaka Fernando <sen...@wso2.com> >>> wrote: >>> >>>> Hi Danesh, Eranda, >>>> >>>> I think we are doing too much here. Before going ahead with this kind >>>> of different subscription model, we need to understand the requirement >>>> here. At least I'm not clear on that. Do you want it to be configurable as >>>> to whether people want to subscribe for association updates etc? or do you >>>> want to simply stop people getting multiple notifications? >>>> >>>> Also, we cannot literally get rid of the handler approach. Its either a >>>> handler or it has to be burnt into the kernel. I personally don't think the >>>> kernel needs this massive feature and if we take that approach we'll be >>>> tailoring the kernel to suit components. But, lets try to clarify the above >>>> before trying to do anything new. >>>> >>>> Thanks, >>>> Senaka. >>>> >>>> >>>> On Mon, Aug 18, 2014 at 1:28 PM, Eranda Sooriyabandara <era...@wso2.com >>>> > wrote: >>>> >>>>> Hi Senaka, >>>>> >>>>> >>>>> On Mon, Aug 18, 2014 at 5:26 PM, Danesh Kuruppu <dan...@wso2.com> >>>>> wrote: >>>>> >>>>>> Hi Senaka, >>>>>> >>>>>> In the current system, event capturing is done through handlers. We >>>>>> couldn't come up with a solution through handlers. >>>>>> >>>>>> >>>>> As we went through the code and the complexity of change should be >>>>> done in order to achieve this with the RegistryEventHandler and the >>>>> handler >>>>> architecture is bit complected. Hence we thought of go for a different >>>>> solution where we introduce a new subscription type in governance level >>>>> and >>>>> we allow subscribe in artifact listing page where other subscriptions will >>>>> remain the same. As Danesh's figure we will do subscribing and >>>>> unsubscribing using the list view. >>>>> We understand that this will complicate the list view but if we add >>>>> this in the resource level then the normal subscription story will break. >>>>> There will be complications with the following areas. >>>>> >>>>> 1. How to show different event and notification types. We are >>>>> planning to have a pop-up which has the similar view as our normal >>>>> subscription >>>>> 2. Managing existing subscriptions. As I mentioned in 1 since we >>>>> use the similar view as our normal subscription it will come with the >>>>> view >>>>> and delete option for existing subscription. >>>>> >>>>> Also there is a problem of notifying in governance API since >>>>> governance API can be use as a client library, need to find a solution. >>>>> >>>>> thanks >>>>> Eranda >>>>> >>>>> >>>>> >>>>> >>>>>> Current suggested solution is, >>>>>> >>>>>> We are giving another subscribe button in artifact level(in List >>>>>> view) which is used for subscribe Artifact update and delete [Please find >>>>>> the attached screenshot]. other subscriptions(check/uncheck LC, remove >>>>>> LC, >>>>>> approve LC etc) are not going to change and are done in resource level. >>>>>> So user can subscribe to update and delete notifications in Artifact >>>>>> level and they will handle separately. >>>>>> >>>>>> Please give feedback on this. >>>>>> >>>>>> Thanks >>>>>> >>>>>> >>>>>> On Fri, Aug 15, 2014 at 8:50 PM, Shavantha Weerasinghe < >>>>>> shavan...@wso2.com> wrote: >>>>>> >>>>>>> Hi Danesh >>>>>>> >>>>>>> For notifications cant we have an option where the user gets to >>>>>>> select which group of resources user wants to update by ticking to >>>>>>> enable >>>>>>> and generate notifications for only that area. >>>>>>> >>>>>>> Will that be extra work for the user >>>>>>> >>>>>>> Regards >>>>>>> On Aug 15, 2014 6:09 PM, "Senaka Fernando" <sen...@wso2.com> wrote: >>>>>>> >>>>>>>> Hi Danesh, >>>>>>>> >>>>>>>> Yes, this is problem that we need to fix. >>>>>>>> >>>>>>>> I think we need to find a way to mask notifications for certain >>>>>>>> operations. Ideally the association processing is a part of the update >>>>>>>> and >>>>>>>> doesn't require separate notifications. But, this functionality of >>>>>>>> masking >>>>>>>> should not just be specific to this use-case, but generically usable >>>>>>>> for >>>>>>>> any similar scenario. Before having the call, can you do some research >>>>>>>> and >>>>>>>> propose a solution to this? Based on that, lets discuss. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Senaka. >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 15, 2014 at 1:11 PM, Danesh Kuruppu <dan...@wso2.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Senaka, >>>>>>>>> >>>>>>>>> With the current implementation, If user subscribe to a resource >>>>>>>>> which have multiple associations attached to it, user will receive >>>>>>>>> multiple >>>>>>>>> update notifications for a single update. >>>>>>>>> >>>>>>>>> This is because resource update have multiple repository update >>>>>>>>> and for every repository update system generates update notification. >>>>>>>>> >>>>>>>>> We need to find a way to send single update notification for this. >>>>>>>>> >>>>>>>>> Can we have a call on this please. >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> >>>>>>>>> Danesh Kuruppu >>>>>>>>> Software Engineer >>>>>>>>> WSO2 Inc, >>>>>>>>> Mobile: +94 (77) 1690552 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> >>>>>>>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>>>>>>> Software Architect; WSO2 Inc.; http://wso2.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> * Member; Apache Software Foundation; http://apache.org >>>>>>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: >>>>>>>> +1 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>>>>>> >>>>>>>> >>>>>>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>>>>>> http://linkedin.com/in/senakafernando >>>>>>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . >>>>>>>> Middleware >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Dev mailing list >>>>>>>> Dev@wso2.org >>>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Dev mailing list >>>>>>> Dev@wso2.org >>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Danesh Kuruppu >>>>>> Software Engineer >>>>>> WSO2 Inc, >>>>>> Mobile: +94 (77) 1690552 >>>>>> >>>>>> _______________________________________________ >>>>>> Dev mailing list >>>>>> Dev@wso2.org >>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Eranda Sooriyabandara*Senior Software Engineer; >>>>> Integration Technologies Team; >>>>> WSO2 Inc.; http://wso2.com >>>>> Lean . Enterprise . Middleware >>>>> >>>>> E-mail: eranda AT wso2.com >>>>> Mobile: +94 716 472 816 >>>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>>> Blog: http://emsooriyabandara.blogspot.com/ >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> >>>> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >>>> Software Architect; WSO2 Inc.; http://wso2.com >>>> >>>> >>>> >>>> * Member; Apache Software Foundation; http://apache.org >>>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >>>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>>> >>>> >>>> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >>>> http://linkedin.com/in/senakafernando >>>> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> >>> *Eranda Sooriyabandara*Senior Software Engineer; >>> Integration Technologies Team; >>> WSO2 Inc.; http://wso2.com >>> Lean . Enterprise . Middleware >>> >>> E-mail: eranda AT wso2.com >>> Mobile: +94 716 472 816 >>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>> Blog: http://emsooriyabandara.blogspot.com/ >>> >>> >>> >>> >>> >> >> >> -- >> >> >> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >> Software Architect; WSO2 Inc.; http://wso2.com >> >> >> >> * Member; Apache Software Foundation; http://apache.org >> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >> >> >> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >> http://linkedin.com/in/senakafernando >> <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware >> > > > > -- > > Danesh Kuruppu > Software Engineer > WSO2 Inc, > Mobile: +94 (77) 1690552 > -- *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* Software Architect; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 408 754 7388; ext: 51736*; *M: +44 782 741 1966 Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
