Request start/end (and Glorp)

Hi,

I'm thinking about integrating Glorp with a Seaside app. Based on the earlier conversation on the Glorp group between Esteban Maringolo and Alan Knight (https://groups.google.com/forum/#!topic/glorp-group/pNw3fpPE1wk) three possibilities were offered:

  1. "In the model of a client-server application normally you would create a session when the user logs in and discard it when they log out. In a web application you may want to associate one with the user's session. In a really high-volume application where you don't want to keep a per-user cache around you might create and destroy them more frequently."

This can be done by hitching a ride on #initialize and #unregister, yes?

  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?

Thanks for your time,

—
Daniel Lyons



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Sun, Jan 19, 2014 at 8:41 AM, Daniel Lyons <[hidden email]> wrote:
> Hi,
>
> I'm thinking about integrating Glorp with a Seaside app. Based on the earlier conversation on the Glorp group between Esteban Maringolo and Alan Knight (https://groups.google.com/forum/#!topic/glorp-group/pNw3fpPE1wk) three possibilities were offered:
>
>   1. "In the model of a client-server application normally you would create a session when the user logs in and discard it when they log out. In a web application you may want to associate one with the user's session. In a really high-volume application where you don't want to keep a per-user cache around you might create and destroy them more frequently."
>
> This can be done by hitching a ride on #initialize and #unregister, yes?

Yes.

>   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.

Cheers
Philippe
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Philippe,

On Jan 19, 2014, at 12:17 PM, Philippe Marschall <[hidden email]> wrote:


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.

Thanks,

—
Daniel Lyons



_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Mon, Jan 20, 2014 at 6:57 PM, Daniel Lyons <[hidden email]> wrote:
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
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside