[Seaside] Request start/end (and Glorp)

[Philippe Marschall]

On Mon, Jan 20, 2014 at 6:57 PM, Daniel Lyons <fusion at storytotell.org> wrote:
> Philippe,
>
> On Jan 19, 2014, at 12:17 PM, Philippe Marschall <philippe.marschall at gmail.com> wrote:
>
>> On Sun, Jan 19, 2014 at 8:41 AM, Daniel Lyons <fusion at storytotell.org> wrote:
>>>  2. "Or more likely, empty the cache and re-use them."
>>>
>>> In order to do that, I think I'd need a pool of some kind to check Glorp sessions in/out at request start and completion. Is there a hook in Seaside that the WASession can tie into to do work at those moments?
>>>
>>> I see references to GlorpSession etc. in the Seaside codebase (the class comment on WAApplication, for instance) but I don't see a package with that around. Is this a VW-specific piece of functionality?
>>
>> I don't know but it sounds like somebody already implemented what you need.
>>
>> In JPA/Hinternate you would usually create an
>> EnityManager/HibernateSesion per request (can be done with a request
>> filter). Enities that stay around longer (are referenced from either
>> the session or components) would then get dettached/attached on a per
>> request basis.
>
>
> We are of one mind. :) That's exactly what I'd like to know how to do, with Seaside + Glorp. I have used the pattern you describe from Java extensively.
>
> Any direction as to how to know, with Seaside, when requests begin and end would be greatly appreciated.

WAMutualExclusionFilter >> #handleFiltered:
- make a subclass
- override the method
  - do what you want to happen before
  - set up thread locals or what you need
  - send #handleFiltered: to super (this runs the "normal" request processing)
  - do what you want to happen after in an #ensure: (IIRC it was
possible in Squeak that #ensure: would run in a different process)
  - you can try to get fancy and roll back the database transaction in
case of an exception but you'll have to pay attention to
WAResponseNotification and friends
- add it to your application

Cheers
Philippe