Announcement Announcement Module
Collapse
No announcement yet.
How to return a borrowed object to a pool? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • How to return a borrowed object to a pool?

    Hi everyone,

    This is my first attempt to use AOP, so please forgive me for asking a question that may seem very obvious to you all.

    I'm writing a piece of code to pool sockets (all with the same IP address and port number).

    In order for the client code to be unaware of pooling or Spring working behind, the client needs to have a method called:

    private Socket newSocket() throws UnknownHostException, IOException {
    return new Socket(this.ipAddress, this.port);
    }

    In application context, a method injection is used to return an advised Socket from a Jakarta Commons generic object pool configured in the application context.

    What puzzles me is that Sockets need to be closed and how to do it in such a way that is transparent to the client.

    Through my reading of the reference document, my understanding is that I need to provide a method interceptor to return the Socket to the pool when close() method is called (and not to invoke proceed() method).

    I also need to define the Socket objects as non-singleton and the destroy-method is "close", in the application context.

    Is my understanding correct?

    Are there any important considerations that I have missed?

    A further question: if I define the destroy-method for a bean, will it be wrapped as a DisposableBean so that the close() method can be called by the pool? Or do I have to wrap it up myself?

  • #2
    After a second thought, using MethodInterceptor seems an overkill for one single class to intercept one single method, let alone the complicated configuration.

    I'll most likely be better off to write a wrapper class that subclasses Socket and implements DisposableBean.

    But how can this wrapper class get hold of the pool so that it can return the wrapped Socket back to the pool?

    Comment


    • #3
      The way AOP based pooling works is your create a proxy around the object to be pooled. So that every operation on that "object" will actually do the following on each invocation:
      - Get object from pool
      - Execute actual invocation
      - return object to a pool.

      I don't think this is what you want. It sounds like you want a pool of objects where each object is taken from the pool for extended periods of time. If you were to use a pool managed by Spring, the sockets would be closed when the pool was destroyed, which is when the application context was destroyed, which happens on application shutdown.

      Can you give a little more detail about your problem? I'm particularly interested how long your code needs to hold a socket for.

      Comment


      • #4
        Thanks for your reply, Bill.

        The use case is like this:

        We have a pre-web-services legacy encryption/decryption server that only works in socket communication.

        For every request we receive, we need to send the encrypted text to the server to decrypt it, then we process the request.

        Before returning a response, the clear text is again sent to the server for encryption.

        So, for each interaction with the encryption server, we need to get a socket from the pool, get InputStream, write the message to the InputStream, then get OutputStream and read the response.

        According to your explanation of how AOP pooling works, it seems only work for pooling stateless objects that are by themselves not thread-safe.

        So the solution to my problem may be: instead of pooling Sockets, I should pool an in-house built SocketMessagingClient, each instance holds a Socket and provide the whole send/receive interaction in one method, such as:

        public String sendAndReceive(String request) throws IOException {...}

        What do you think?

        Comment


        • #5
          Sounds perfect. Just make sure you plug the pool as a targetSource to a ProxyFactoryBean that implements your SocketMessagingClient's interface.

          Comment

          Working...
          X