Announcement Announcement Module
Collapse
No announcement yet.
Reconnecting Transient Services Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Reconnecting Transient Services

    I am using Spring to wire a context object that is bound as a ThreadLocal and put in an HttpSession. The context object has a few beans wired to it, which are transient. I'm trying to find a way to get Spring to reconnect those beans on deserialization.

    It doesn't seem that there's any form of read resolver in Spring, which is a little awkward... how does it maintain singleton beans, otherwise?

    Thanks,

    Cris
    Last edited by cris; Jun 16th, 2006, 04:01 PM. Reason: services was probably not the right word to use..

  • #2
    Spring doesn't support serializing/deserializing application context out of the box; that's why there is no read resolver. You could get a hold of the application context somehow but I don't see a clear way to reinject the dependencies back into your object - you could just request a new object from the context and then copy the properties in your object - but that's not very safe or efficient.

    Comment


    • #3
      Originally posted by Costin Leau
      Spring doesn't support serializing/deserializing application context out of the box; that's why there is no read resolver. You could get a hold of the application context somehow but I don't see a clear way to reinject the dependencies back into your object - you could just request a new object from the context and then copy the properties in your object - but that's not very safe or efficient.
      Yeah, this is a weird issue. It requires awkward decisions like "what do I reconnect" and "am I going to change state of the bean by connecting the object". A single strategy would not work well, but I don't think that means this problem can remain unsolved. It isn't that uncommon to have a stateful bean in something like a user session, and it warrants attention. From what I found on the archives, a lot of people have had this problem, and Rod spent some on-list time looking for a solution before the effort fizzled out.

      I think a serializing read-resolving context could be effective. You could use the context configuration to determine how to retrieve the active context, then provide that as a replacement. A null readObject would be provided.

      However, there is a near-term solution that allows users who need a solution to this problem to get by. If the context were a "magic" named bean that you could insert into your object, rather than relying on ApplicationContextAware, then you could use a lookup-method to provide it. I set up a simple ApplicationContextHolder bean that I now provide to my object via lookup-method, and it simply falls back to WebApplicationContextUtils. It's still dependent on how the context is stored, which is less than ideal, but its better than all of my objects being dependent.

      I definitely think creating a bean for the context would go a long way here..

      Cris

      Comment


      • #4
        There were some ideas about injecting objects into objects outside spring (mainly through AspectJ) like Hibernate maintained objects. Ofc, there are others example and I think yours is part of this category.
        Try raising an issue on JIRA and vote on it - allowing serializable/deserializable context has been discussed for a while and after getting 2.0 out it could be included in the roadmap.
        I find the idea interesting since it could also address some problems related to clustering and having a single context across multiple VMs.

        Comment


        • #5
          Originally posted by Costin Leau
          I find the idea interesting since it could also address some problems related to clustering and having a single context across multiple VMs.
          As do I... I think it is a barrier to replacing a lot of EJB deployments, so worth pursuing. I'll add a JIRA and also tinker with some potential solutions.

          Thanks!

          Comment


          • #6
            We're trying something along the following lines:

            An interface defines the state that can be contained/bound.

            A manually created (outside of spring) proxy holds:
            1. A transient reference to the bean
            2. The name of the Bean
            3. A static reference to a beanfactory.
            4. Some state

            Upon serialization/deserialization, #1 becomes null, the proxy recognizes that and requests a replacement (from #3) for bean name (#2) and rebinds the state (#4) into the replacement object. (expensive)

            This feels hokey/kludgey, because this is the type of thing I'd like for the container to hide completely from my app code, but thus far I haven't seen a good way to implement a proxyfactory+proxy that could mimic this functionality.

            The alternatives I've seen are:
            1. Ones that avoid putting anything with a connection to a bean factory in an HttpSession.
            2. Pass the HttpSession (or what you need out of it, or an adapter to it) down through the layers of your app on a threadlocal via a ServletFilter.

            Regards,
            Matt

            http://netsmith.wikispaces.com - Development notes/patterns/practices + Some Spring stuff

            Comment

            Working...
            X