On Mon, Mar 26, 2012 at 12:04 PM, Prabath Abeysekera <[email protected]>wrote:
> Hi all, > > I've been working on the $subject and currently there's only one task > remaining to be completed. The main intention of this effort is to migrate > the existing task implementation of BAM to ntasks which is a quartz based > task scheduler component introduced a couple of months back. While working > on the aforementioned bit of remaining work, I was confronted with an issue > and here's my suggestions to overcome it. > > In the currently used BAM task implementation, there's a mechanism called > DataContext which is used to pass some runtime data to a particular task > execution (such as default credentials to log into cassandra, tenant ID, > etc) and to populate it with records that are fetched from cassandra (using > the GetAnalyser) in memory. Whenever a task is scheduled this object is > passed into it which then uses the DataContext object to grab the necessary > runtime information required for the task execution. Ntasks being a generic > task scheduler component, only accepts a map of string key value pairs as > run time properties. In other words, if it is required to pass additional > set of properties apart from the ones that are provided by default (for > example, cron expression, task count, task interval, etc) then they have to > be passed as Strings. Thus, we either need to serialize the DataContext or > we need to find some other mechanism to pass those properties in the > DataContext to the corresponding task. > > Currently the DataContext is used as a holder for data fetched from Cassandra and so the serializing of DataContext is not trivial and not very useful as well. IIUC, I believe it would be more appropriate if it is possible to make the > DataContext local to the task execution since a task being a single > independent execution unit and the DataContext is also bound to a > particular task. To elaborate more on this, the DataContext seems to be > effectively used in the task execution phase, so I believe, there's a > possibility for us to build it up at the aforementioned phase without > initializing it in the task scheduling phase. This way we can even get rid > of the usage of the binding of DataContext at the task scheduling phase. > And we can also pass the properties of the DataContext as String key value > pairs as well. > +1. This decouples run time data and configuration data currently present in the DataContext. We can basically use DataContext for holding run time data (basically fetched data) which would be specific for the particular execution of the task. > Had an offline chat with Tharindu on this and we agreed to proceed with > the above suggested mechanism which involves removing the binding of the > DataContext object at the task scheduling phase. > > > > Regards, > -- > Prabath Abeysekara > Software Engineer > WSO2 Inc. > Email: [email protected] <[email protected]> > Mobile: +94774171471 > > <http://harshana05.blogspot.com/> > > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > Regards Buddhika
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
