[ https://forge.continuent.org/jira/browse/SEQUOIA-963?page=all ]
Robert Hodges resolved SEQUOIA-963:
-----------------------------------
Assign To: Tommi Takkunen-Lauri (was: Robert Hodges)
Resolution: Fixed
Fix Version: (was: Sequoia 2.9)
sequoia 2.10.10
Release Note: Implement request interceptor feature so that users can add
code to look at and transform SQL requests
Completed merge of code from Branch_Sequoia_963. This feature is now in
Sequoia and fully usable.
> Add RequestInterceptor feature to allow easy addition of logic to monitor and
> transform requests
> ------------------------------------------------------------------------------------------------
>
> Key: SEQUOIA-963
> URL: https://forge.continuent.org/jira/browse/SEQUOIA-963
> Project: Sequoia
> Type: New Feature
> Components: Core
> Versions: Sequoia 2.9
> Environment: All
> Reporter: Robert Hodges
> Assignee: Tommi Takkunen-Lauri
> Priority: Critical
> Fix For: sequoia 2.10.10
>
> Original Estimate: 1 week
> Remaining: 1 week
>
> It is a common requirement to want to add additional logic that can piggyback
> on top of requests in order to monitor or transform them. Here are some
> examples:
> 1.) Checking for SQL that is forbidden by a particular application.
> 2.) Performing transformation on SQL such as adding comments to make it
> easier to implement replication strategies between clusters.
> 3.) Logging interesting information about requests.
> To enable these types of applications I plan to add a new feature called a
> RequestInterceptor, which is a specialized interface that is invoked within
> VirtualDatabaseWorker threads immediate prior to submitting SQL to the VDB
> for execution. The RequestInterceptor is invoked and will receive the
> Request as well as some additional information like the VDB object. The
> RequestInterceptor can examine the request, make well-defined changes, and
> perform functions like logging or monitoring as desired.
> The implementation will be approximately as follows.
> 1.) The RequestInterceptor interface will have a method that is invoke for
> each request. Implementations can perform arbitrary processing in this
> method. Multiple RequestInterceptors can be added in which case the
> processing methods are invoked in succession.
> 2.) Request data will be passed in using interfaces that wrap the underlying
> AbstractRequest object. The interfaces will expose only a limited amount of
> information and prevent unfortunate transformations that might cause further
> processing to fail. There may be additional information passed in such as
> the VDB and an abstraction of information in the VirtualDatabaseWorkerThread
> (i.e., the closest thing we have to a session).
> 3.) There will be a mechanism to configure zero or more RequestInterceptors
> for each controller and define parameters for each RequestInterceptor
> implementation. This may require an additional configuration file.
> 4.) There will be a well-defined lifecycle for RequestInterceptor instances
> in which they are initialized with configuration data, invoked zero or more
> times, and shut down at controller termination.
> 5.) The data structures associated with the RequestInterceptor will be
> largely free of dependencies on other Sequoia packages and will be easy to
> unit test outside the controller.
> This mechanism will apply to request on the way in to the VDB only. Later on
> it may make sense to enlarge the feature to permit RequestInterceptors to
> generate errors or their own result sets.
> Comments and suggestions are welcome. I hope this will turn out to be a
> useful feature for Sequoia users.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://forge.continuent.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
_______________________________________________
Sequoia mailing list
[email protected]
https://forge.continuent.org/mailman/listinfo/sequoia
