Announcement Announcement Module
No announcement yet.
OSIV and reconnecting domain object to session Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • OSIV and reconnecting domain object to session


    I have been struggling with the following issue. I have a Customer object which has a many-to-one relationship with a Contact object using Hibernate. Both objects are set to lazy="true". I am currently using the OSIV in singleSession mode.

    1. On a GET, the controller queries the database for the Customer object and then passes it back to the view which spits out the information, including the Contact object's info.

    2. The view allows for editing of the information. So, when a person edits the info and then clicks submit, Spring automatically binds the properties from the front-end.

    3. After Spring binds, I pass the Customer object to my service layer, which in turn calls a DAO to save the Customer object and any changes to the Contact object (I have cascading on save-update).

    However, since I am using singleSession mode in the OSIV, I need to reconnect the Customer object to the session BEFORE Spring binds the properties. How can I do this? How are others' handling this situation?

    Thanks for any help,


  • #2
    I don't much like OSIV, nor singleSession="true"...
    But it seems to me like you could add a method in your DAO that says something like:
    public void reconnect(Object entity) {
        this.getHibernateTemplate().lock(entity, LockMode.NONE);
    ... or using your entity superclass (or superinterface) instead of Object if you have one.
    On the service layer, wrap this any way you like...
    Then, turn off sessionForm on your controller:
    public MyController() {
    And get the object from the session yourself:
    protected Object formBackingObject(HttpServletRequest request) throws ServletException {
        Customer customer = null;
        if (isFormSubmission()) {
            customer = this.getCustomerFromSession(request);
        } else {
            customer = this.getCustomer(request);
        return customer;
    All completely untested code, mind you!
    Best regards,


    • #3
      Thanks for your reply Assaf.

      Your solution is definitely one I considered and will probably try out to see if it works. What kind of solution are you using to perform the same kind of action. I feel like this solution is kind of forced and was wondering what the best way to accomplish all of this stuff is. Everyone keeps saying that DTOs are evil, but the time I've spent struggling with this lazy initialization stuff I could've written the DTOs 100 times over. Obviously my use case is a pretty common thing.....

      Thanks again for your help,



      • #4
        Hi Rexxe,

        Well, I've been avoiding session forms (I've never much liked keeping domain objects lying around in the session - what if the session times out?), the main cost of which seems to be that I have to implement my own optimistic locking strategy.

        I've also eventually dumped OSIV completely, cause it caused more trouble than it solved - it tends to be used as a replacement for transactions rather than as a way of accessing lazy collections in the view.

        My initial approach after form submission was thus as follows:
        1) load the domain object based on a request parameter. My load methods in the service layer generally look something like:
        public Customer loadCustomer(Long customerId, boolean touchCollections) {
           Customer customer = customerDao.loadCustomer(customerId);
           if (touchCollections)
           return customer;
        ... where touchCollections is defined on my Entity interface, and basically forces a load of lazy-loaded collections by querying their size.
        2) allow Spring to bind to the domain object and do any custom binding
        3) in onSubmit(), persist the domain object using a Hibernate saveOrUpdate()

        However, because I find this collection touching to be a bit of a nuisance, I've been considering another approach in which the loading, binding and persisting all occur within a single service-layer transaction. I just posted a related post in the architecture discussion.

        Hope this makes sense.

        Best regards,
        Last edited by robyn; May 19th, 2006, 05:22 AM.