Announcement Announcement Module
Collapse
No announcement yet.
keeping result set open in view layer Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • keeping result set open in view layer

    Part of our application requires the export of large quantities of data to CSV over HTTP. Initially, we implemented this by performing the query in Hibernate, returning a list to controller, putting the list in a model, then iterating over the list in a view that renders it as CSV. However, this is causing memory issues as the list contains a lot of data.

    I've tried reimplementing this by returning a ScrollableResults object to the view and scrolling through this, so that the entire list does not need to be held in memory. However, this fails because the underlying JDBC result set is being closed between the controller and view. It is being closed when the transaction commits, which happens in the transaction interceptor that we have around all controllers.

    We are using Spring 1.2, Websphere 6.0 and Hibernate 3.1. We also have the open-session-in-view filter, which I would have thought would be able to keep the database connection open in the view, but it appears not in this case.

    Can anyone think of a way around this?

  • #2
    Why not create the csv on the server and send that instead of a list of objects?

    We are using Spring 1.2, Websphere 6.0 and Hibernate 3.1. We also have the open-session-in-view filter, which I would have thought would be able to keep the database connection open in the view, but it appears not in this case.
    It keeps the session open, if you use plain jdbc then it doesn't keep your connection open, the OpenSession part should give that away .

    Comment


    • #3
      Originally posted by mdeinum View Post
      Why not create the csv on the server and send that instead of a list of objects?
      I assume by "server" you mean "controller"? I suppose that I could do this, but it would mean either keeping the entire CSV in memory (rather than buffering it to the client), or writing it directly to the HttpServletResponse and bypassing Spring MVC's controller/view detachment. In terms of memory usage, keeping the entire CSV in memory is not much better than keeping the list of objects.

      Comment


      • #4
        I assume by "server" you mean "controller"? I suppose that I could do this, but it would mean either keeping the entire CSV in memory (rather than buffering it to the client), or writing it directly to the HttpServletResponse and bypassing Spring MVC's controller/view detachment
        I actually meant server, I expected your Object tree to be larger then the CSV. However streaming it would be even better. Why would it be bypassing? They even suggest it in the reference guide for streaming images for instance... Now you have added a jsp which contains logic which it shouldn't contain imho and adds another (thus unnecessary layer).

        I think setting the response type, filename and then stream it to the client is perfectly legal. Return null as your ModelAndView and you should be good to go.

        Comment

        Working...
        X