HibernateSessionSource.create(); On Wed, Sep 1, 2010 at 3:19 PM, Norman Franke <nor...@myasd.com> wrote: > Right, so my question was, can I get Tapestry IoC to create me a new session > for this new thread that won't be affected by anything else. I could > duplicate the (lots) of code in the request filter, but that seems wrong. > > Norman Franke > Answering Service for Directors, Inc. > www.myasd.com > > > > On Sep 1, 2010, at 6:11 PM, Kalle Korhonen wrote: > >> On Wed, Sep 1, 2010 at 2:46 PM, Norman Franke <nor...@myasd.com> wrote: >>> >>> The new thread is the one that will run in the background. My concern, >>> and >>> it may not be a concern, is that the request processing will have created >>> my >>> DAO objects associated with a Hibernate session in that thread, and I'll >>> access it from another thread (the one running in the background.) I was >>> worried that when the request finishes, Tapestry will release the DAO and >>> Hibernate session. >> >> Right. The DAOs don't matter (or if they do, you've designed them >> wrong), the entities do. The entity objects will become detached from >> the session after its closed. Don't hold onto the session longer than >> you have to, and remember that if you didn't create the session >> yourself, don't close it yourself and vice versa. If you are just >> (periodically) reading from the database, you'll only run into session >> issues in case you are using lazily-loaded objects. If you write >> periodically, make sure your entities are attached to a separate >> session. >> >> Kalle >> >> >>> On Sep 1, 2010, at 5:27 PM, Kalle Korhonen wrote: >>> >>>> Thread safety is your responsibility, but services are singleton by >>>> default and it shouldn't matter to your DAOs which threads they are >>>> accessed from. What you need to worry about is the consistency of your >>>> data. When you say "the new thread is created to process the data", >>>> what do you mean by it? If you are just writing to the database, then >>>> the database will handle the integrity of the data. If you do some >>>> in-memory processing of the data, then the integrity of it is yours to >>>> handle. >>>> >>>> Kalle >>>> >>>> >>>> On Wed, Sep 1, 2010 at 2:12 PM, Norman Franke <nor...@myasd.com> wrote: >>>>> >>>>> Will there be some issue with the injected services? This async service >>>>> when >>>>> created will have it's injected services created in the thread of the >>>>> current web request. When the new thread is created to process the >>>>> data, >>>>> the >>>>> services will then be accessed from a different thread. >>>>> >>>>> Norman Franke >>>>> Answering Service for Directors, Inc. >>>>> www.myasd.com >>>>> >>>>> >>>>> >>>>> On Sep 1, 2010, at 4:03 PM, Kalle Korhonen wrote: >>>>> >>>>>> ParallelExecutor is a "service that allows work to occur in parallel >>>>>> using a thread pool". I doubt it's usefulness in your case. Simply >>>>>> create a new service, spawn threads in it as needed to do work and >>>>>> implement a few get status operations that your page(s) can call. That >>>>>> way, keeping the page up-to-date via AJAX is a separate concern. >>>>>> >>>>>> Kalle >>>>>> >>>>>> >>>>>> On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke <nor...@myasd.com> >>>>>> wrote: >>>>>>> >>>>>>> I need a page that will start a long-running process involving heavy >>>>>>> use >>>>>>> of >>>>>>> a database. I'm trying to come up with an elegant way to integrate >>>>>>> this >>>>>>> into >>>>>>> my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate >>>>>>> DAOs. >>>>>>> Then I'd like to write status updates to a stack and have an AJAX >>>>>>> process >>>>>>> poll and update the web page with what's happening. >>>>>>> >>>>>>> I see there is a ParallelExecutor in Tapestry, but I don't think it >>>>>>> does >>>>>>> injection. >>>>>>> >>>>>>> Any good solutions out there? >>>>>>> >>>>>>> Norman Franke >>>>>>> Answering Service for Directors, Inc. >>>>>>> www.myasd.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > >
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
