{"id":10,"date":"2009-07-07T20:44:40","date_gmt":"2009-07-07T19:44:40","guid":{"rendered":"http:\/\/katastrophos.net\/magnus\/blog\/?p=10"},"modified":"2009-07-12T22:03:04","modified_gmt":"2009-07-12T21:03:04","slug":"detached-service-methods-with-spring-aop","status":"publish","type":"post","link":"https:\/\/jungsbluth.de\/magnus\/blog\/2009\/07\/07\/detached-service-methods-with-spring-aop\/","title":{"rendered":"Detached Service Methods with Spring AOP"},"content":{"rendered":"

In a typical spring based server application there is a service layer responsible for infrastructure tasks and communication with the clients. Service methods can be long running and execution would normally block the user-interface. Putting the client side end of the call in a thread solves the blocking but leaves the network connection open while the server side of the call is active. This can lead to all sorts of time-out issues and seems to be the wrong end to fix the problem .<\/p>\n

Using spring AOP it is remarkably easy to declaratively enable service methods to execute detached from the regular call context.<\/p>\n

The Goal<\/h4>\n
@DeferredExecution\r\npublic myServiceMethod() throws DeferredExecutionException {\r\n}<\/pre>\n
This method would execute with the following sematics:<\/p>\n
    \n
  1. The regular method call is wrapped in a thread<\/li>\n
  2. The thread is executed<\/li>\n
  3. If the thread does not finish within x seconds, raise a checked exception<\/li>\n
  4. If it does finish in time, return the result of the method<\/li>\n<\/ol>\n
    This way clients of this method are forced to handle detached execution (i.e. show a progress dialog querying the server) and the client side of the call not langer lasts longer than a set time.
    \n<\/p>\n
    Implementation<\/h4>\n
    Define a new Annotation<\/p>\n
    \r\n@Target(ElementType.METHOD)\r\n@Retention(RetentionPolicy.RUNTIME)\r\npublic @interface DeferredExecution {\r\n}<\/pre>\n
    Define a spring aspect (note that altough it uses AspectJ annotations, AspectJ is not required)<\/p>\n
    \r\n@Aspect\r\npublic class DeferredExecutionInterceptor implements Ordered {\r\n\r\n\tprivate int order;\r\n\r\n\t@Pointcut(\"execution(* *.*(..)) && @annotation(DeferredExecution)\")\r\n\tpublic void inServiceMethod() {}\r\n\r\n\t@Around(\"inServiceMethod()\")\r\n\tpublic Object doDeferredExecution(ProceedingJoinPoint joinPoint) \r\n\t\t\tthrows Throwable {\r\n\t\tJoinPointExecutionThread thread = new JoinPointExecutionThread(joinPoint);\r\n\t\tthread.start();\r\n\r\n\t\t\/\/wait for the thread to finish and\r\n\t\t\/\/- either throw a DeferredExecutionException\r\n\t\t\/\/- or return the result\r\n\t}\r\n\r\n\t@Override\r\n\tpublic int getOrder() {\r\n\t\treturn order;\r\n\t}\r\n\r\n\tpublic void setOrder(int order) {\r\n\t\tthis.order = order;\r\n\t}\r\n}<\/pre>\n
    It is important to implement the Ordered interface since you most likely want to influence the order of the created AOP-Proxy. It should run after a security advisor and before any transaction interceptor.<\/p>\n
    The following spring config brings this aspect to life. The aspect is applied to all spring managed instances.<\/p>\n
    \r\n<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n<beans \r\n  xmlns=\"http:\/\/www.springframework.org\/schema\/beans\"\r\n  xmlns:xsi=\"http:\/\/www.w3.org\/2001\/XMLSchema-instance\"\r\n  xmlns:aop=\"http:\/\/www.springframework.org\/schema\/aop\"\r\n  xsi:schemaLocation=\"\r\n    http:\/\/www.springframework.org\/schema\/beans \r\n    http:\/\/www.springframework.org\/schema\/beans\/spring-beans-2.5.xsd \r\n    http:\/\/www.springframework.org\/schema\/aop \r\n    http:\/\/www.springframework.org\/schema\/aop\/spring-aop-2.5.xsd\">\r\n\r\n    <aop:aspectj-autoproxy \/>\r\n\r\n    <bean id=\"deferredExecutionInterceptor\" class=\"DeferredExecutionInterceptor\">\r\n        <property name=\"order\" value=\"100\" \/>\r\n    <\/bean>\r\n\r\n    <bean id=\"testService\" class=\"TestServiceImpl\">\r\n    <\/bean>\r\n<\/beans>\r\n<\/pre>\n
    There is one tiny bit that is optional: Nothing prevents a developer not to declare a throws clause on an annotated service method. Since client code must<\/strong> handle the case when execution is detached, this is crucial. <\/p>\n
    To enforce this at compile time<\/strong> we can use AspectJ’s declare error feature to generate a compile error when such an inconsistency is found.<\/p>\n
    Create a separate<\/strong> Aspect with<\/p>\n
    \r\npublic aspect DeferredExecutionMethodCheckAspect {\r\n\t\t\r\n\tpublic pointcut deferredExecutionMethodWithoutThrows(): \r\n\t\texecution(@DeferredExecution public * *.* (..)) \r\n\t\t&& !execution(@DeferredExecution public * *.* (..) \r\n\t\t\t\tthrows DeferredExecutionException);\r\n\t\r\n\tdeclare error: deferredExecutionMethodWithoutThrows(): \r\n\t\t\"Method must declare throws DeferredExecutionException for annotation to work\";\r\n}\r\n<\/pre>\n
    When configuring compile time weaving in maven or AJDT it is crucial not to weave<\/strong> DeferredExecutionInterceptor, since this would make it impossible to set the order in which spring executes the AOP Proxies. <\/p>\n
    Remarks<\/h4>\n
    This is of course only a rough sketch but it worked almost instantly. Note that there is no documentation concerning the thread safety of the joinPoint passed into the around advice. Since the joinPoint is only used within one thread it seems safe to to so. <\/p>\n
    In a real world scenario you would most likely not use threads directly but your choice for handling background jobs (for example backed by Quartz).<\/p>\n
    Note that there is no mechanism to handle cascaded service calls. You would most likely want only one background job created along the way. This could easily be solved using ThreadLocals…<\/p>\n