Smalltalk › Frameworks & Tools › Seaside › Seaside General

Glorp Sessions in ajax requests

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

10 messages Options

Bart Veenstra

Glorp Sessions in ajax requests

Hi,

I am working on an Ajax heavy application with Glorp as my mapping framework. I use the Glorp filter to assign a glorpSession to my database objects. This works pretty well, but it seems that for each request within the same session (like an jQuery ajax callback) a new GlorpSession is created.

When removing all sessions using WAAdmin clearAll, the Glorp Sessions still remain in the memory, (Checked with GlorpSession allInstances).

Should I worry about this? And how do I get rid of the GlorpSessions?

I tried GlorpSession allInstances do: [:each | each become:nil ] but the object is immutable...

Using VW 77 with the latest seaside from the public repository.

Regards,

Bart Veenstra

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

Bart Veenstra

Re: Glorp Sessions in ajax requests

And another thing is bugging me during the development.

How do I cope with glorp objects that are stored in a WAComponent, like the current user, and use that when I update other glorp objects. It keeps pushing me a DuplicatePrimaryKeyException because the object is not in the current session. I need to reinstantiate the current user in the session with a database lookup, before I can use it again...

So, How to properly mix glorp objects coming from different sessions? This could be resolved, if the glorpFilter stays put in the WASession in each ajax request.

Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

Regards,

Bart

2010/9/10 Bart Veenstra <[hidden email]>

Hi,

I am working on an Ajax heavy application with Glorp as my mapping framework. I use the Glorp filter to assign a glorpSession to my database objects. This works pretty well, but it seems that for each request within the same session (like an jQuery ajax callback) a new GlorpSession is created.

When removing all sessions using WAAdmin clearAll, the Glorp Sessions still remain in the memory, (Checked with GlorpSession allInstances).

Should I worry about this? And how do I get rid of the GlorpSessions?

I tried GlorpSession allInstances do: [:each | each become:nil ] but the object is immutable...

Using VW 77 with the latest seaside from the public repository.

Regards,

Bart Veenstra

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

John McKeon

Re: Glorp Sessions in ajax requests

Have a look at the Seaside-Glorp package. It should be in the public repository (and comes prepackaged with WebVelocity) provides for Seaside session-glorp session "persistence", accessor pooling, etc. The package comments say it is based on work by Ramon Leon so you might check his blog to see if you can glean some hints there

John

On Fri, Sep 10, 2010 at 2:27 PM, Bart Veenstra <[hidden email]> wrote:

And another thing is bugging me during the development.

How do I cope with glorp objects that are stored in a WAComponent, like the current user, and use that when I update other glorp objects. It keeps pushing me a DuplicatePrimaryKeyException because the object is not in the current session. I need to reinstantiate the current user in the session with a database lookup, before I can use it again...

So, How to properly mix glorp objects coming from different sessions? This could be resolved, if the glorpFilter stays put in the WASession in each ajax request.

Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

Regards,

Bart

2010/9/10 Bart Veenstra <[hidden email]>

Hi,

I am working on an Ajax heavy application with Glorp as my mapping framework. I use the Glorp filter to assign a glorpSession to my database objects. This works pretty well, but it seems that for each request within the same session (like an jQuery ajax callback) a new GlorpSession is created.

When removing all sessions using WAAdmin clearAll, the Glorp Sessions still remain in the memory, (Checked with GlorpSession allInstances).

Should I worry about this? And how do I get rid of the GlorpSessions?

I tried GlorpSession allInstances do: [:each | each become:nil ] but the object is immutable...

Using VW 77 with the latest seaside from the public repository.

Regards,

Bart Veenstra

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

--
http://john-mckeon.us

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

Sven Van Caekenberghe

Re: Glorp Sessions in ajax requests

In reply to this post by Bart Veenstra

Bart,

On 10 Sep 2010, at 20:27, Bart Veenstra wrote:

> Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

I think you would have more control / better understand thinks with a WASession subclass, like here:

http://homepage.mac.com/svc/Reddit.st/#s6

How that interacts with Ajax, I don't know.

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

Bart Veenstra

Re: Glorp Sessions in ajax requests

HI Sven,

I am using a slightly modified version of the the Seaside-Glorp package because I my database settings are stored in a configuration file. That way, I would not have to reconfigure the app when I register it again.

Does anyone have used the Seaside-Glorp package in an ajax applications? And how do you cope with objects which are from a different session?

2010/9/10 Sven Van Caekenberghe <[hidden email]>

Bart,

On 10 Sep 2010, at 20:27, Bart Veenstra wrote:

> Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

I think you would have more control / better understand thinks with a WASession subclass, like here:

http://homepage.mac.com/svc/Reddit.st/#s6

How that interacts with Ajax, I don't know.

Sven_______________________________________________

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

Alan Knight-2

Re: Glorp Sessions in ajax requests

In reply to this post by Bart Veenstra

In general, if you've got objects from different sessions, then yes, you're going to have to read it for the current session, or fake around it in interesting ways. It seems like the issue is why you're getting a different Glorp session for each Ajax request. I haven't looked at the details of the code, but I'm guessing that the mode it's operating in is that each http request is getting a separate glorp session and releasing it back to the pool again immediately, or just discarding it, and when an ajax request comes in it's being treated as a separate request, and getting a new session. So what you'd want to do is keep the Glorp session associated with the Seaside session, and re-use it for each request that comes in. You'd presumably want to make sure you're pooling the underlying database connections then, but that's fine. The details of that, and whether the framework already lets you do that are left as an exercise to the reader, as I'm in Barcelona enjoying myself prior to the start of ESUG :-)

At 02:27 PM 2010-09-10, Bart Veenstra wrote:

And another thing is bugging me during the development.

How do I cope with glorp objects that are stored in a WAComponent, like the current user, and use that when I update other glorp objects. It keeps pushing me a DuplicatePrimaryKeyException because the object is not in the current session. I need to reinstantiate the current user in the session with a database lookup, before I can use it again...

So, How to properly mix glorp objects coming from different sessions? This could be resolved, if the glorpFilter stays put in the WASession in each ajax request.

Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

Regards,

Bart

2010/9/10 Bart Veenstra <[hidden email] >

Hi,

I am working on an Ajax heavy application with Glorp as my mapping framework. I use the Glorp filter to assign a glorpSession to my database objects. This works pretty well, but it seems that for each request within the same session (like an jQuery ajax callback) a new GlorpSession is created.

When removing all sessions using WAAdmin clearAll, the Glorp Sessions still remain in the memory, (Checked with GlorpSession allInstances).

Should I worry about this? And how do I get rid of the GlorpSessions?

I tried GlorpSession allInstances do: [:each | each become:nil ] but the object is immutable...

Using VW 77 with the latest seaside from the public repository.

Regards,

Bart Veenstra

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

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

http://www.cincom.com/smalltalk

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

Bart Veenstra

Re: Glorp Sessions in ajax requests

To bad I can't make it to Barcalona this yeah... I'll bet you all have a great time over there! Next year i'll definitly be at esug and / or Vegas :)

I will dedicate this weekend for getting Glorp sessions be maintained over a WASession.

@Sven, I will use you reddit application as a blue print and publish my findings over the weekend.

Regards,

Bart

2010/9/10 Alan Knight <[hidden email]>

In general, if you've got objects from different sessions, then yes, you're going to have to read it for the current session, or fake around it in interesting ways. It seems like the issue is why you're getting a different Glorp session for each Ajax request. I haven't looked at the details of the code, but I'm guessing that the mode it's operating in is that each http request is getting a separate glorp session and releasing it back to the pool again immediately, or just discarding it, and when an ajax request comes in it's being treated as a separate request, and getting a new session. So what you'd want to do is keep the Glorp session associated with the Seaside session, and re-use it for each request that comes in. You'd presumably want to make sure you're pooling the underlying database connections then, but that's fine. The details of that, and whether the framework already lets you do that are left as an exercise to the reader, as I'm in Barcelona enjoying myself prior to the start of ESUG :-)

At 02:27 PM 2010-09-10, Bart Veenstra wrote:

And another thing is bugging me during the development.

How do I cope with glorp objects that are stored in a WAComponent, like the current user, and use that when I update other glorp objects. It keeps pushing me a DuplicatePrimaryKeyException because the object is not in the current session. I need to reinstantiate the current user in the session with a database lookup, before I can use it again...

So, How to properly mix glorp objects coming from different sessions? This could be resolved, if the glorpFilter stays put in the WASession in each ajax request.

Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

Regards,

Bart

2010/9/10 Bart Veenstra <[hidden email] >

Hi,

I am working on an Ajax heavy application with Glorp as my mapping framework. I use the Glorp filter to assign a glorpSession to my database objects. This works pretty well, but it seems that for each request within the same session (like an jQuery ajax callback) a new GlorpSession is created.

When removing all sessions using WAAdmin clearAll, the Glorp Sessions still remain in the memory, (Checked with GlorpSession allInstances).

Should I worry about this? And how do I get rid of the GlorpSessions?

I tried GlorpSession allInstances do: [:each | each become:nil ] but the object is immutable...

Using VW 77 with the latest seaside from the public repository.

Regards,

Bart Veenstra

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

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
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

Boris Popov, DeepCove Labs (SNN)

Re: Glorp Sessions in ajax requests

In reply to this post by Bart Veenstra

Which version of Seaside-Glorp are you using? It works fine on VisualWorks w/o spawning new Glorp sessions.

-Boris (via BlackBerry)

From: [hidden email] <[hidden email]>
To: Seaside - general discussion <[hidden email]>
Sent: Sat Sep 11 04:12:04 2010
Subject: Re: [Seaside] Re: Glorp Sessions in ajax requests

To bad I can't make it to Barcalona this yeah... I'll bet you all have a great time over there! Next year i'll definitly be at esug and / or Vegas :)

I will dedicate this weekend for getting Glorp sessions be maintained over a WASession.

@Sven, I will use you reddit application as a blue print and publish my findings over the weekend.

Regards,

Bart

2010/9/10 Alan Knight <[hidden email]>

In general, if you've got objects from different sessions, then yes, you're going to have to read it for the current session, or fake around it in interesting ways. It seems like the issue is why you're getting a different Glorp session for each Ajax request. I haven't looked at the details of the code, but I'm guessing that the mode it's operating in is that each http request is getting a separate glorp session and releasing it back to the pool again immediately, or just discarding it, and when an ajax request comes in it's being treated as a separate request, and getting a new session. So what you'd want to do is keep the Glorp session associated with the Seaside session, and re-use it for each request that comes in. You'd presumably want to make sure you're pooling the underlying database connections then, but that's fine. The details of that, and whether the framework already lets you do that are left as an exercise to the reader, as I'm in Barcelona enjoying myself prior to the start of ESUG :-)

At 02:27 PM 2010-09-10, Bart Veenstra wrote:

And another thing is bugging me during the development.

How do I cope with glorp objects that are stored in a WAComponent, like the current user, and use that when I update other glorp objects. It keeps pushing me a DuplicatePrimaryKeyException because the object is not in the current session. I need to reinstantiate the current user in the session with a database lookup, before I can use it again...

So, How to properly mix glorp objects coming from different sessions? This could be resolved, if the glorpFilter stays put in the WASession in each ajax request.

Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

Regards,

Bart

2010/9/10 Bart Veenstra <[hidden email] >

Hi,

I am working on an Ajax heavy application with Glorp as my mapping framework. I use the Glorp filter to assign a glorpSession to my database objects. This works pretty well, but it seems that for each request within the same session (like an jQuery ajax callback) a new GlorpSession is created.

When removing all sessions using WAAdmin clearAll, the Glorp Sessions still remain in the memory, (Checked with GlorpSession allInstances).

Should I worry about this? And how do I get rid of the GlorpSessions?

I tried GlorpSession allInstances do: [:each | each become:nil ] but the object is immutable...

Using VW 77 with the latest seaside from the public repository.

Regards,

Bart Veenstra

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

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
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

Bart Veenstra

Re: Glorp Sessions in ajax requests

In reply to this post by Bart Veenstra

Putting the glorp session into an instance variable, does seem limit the creation of glorp sessions, however they are not collected by the carbage collector when removing the sessions.

I am using the VWPoolingDatabaseAccessor for creating the accessor for the glorp session. These also remain image. Once I clean those up using:

VWPoolingDatabaseAccessor allInstances do: [:each | each become:nil ].

The Glorp Sessions are removed as well.

I create a Glorp Session using:

newGlorpSession

| accessor |

Transcript cr; show: self key , ' Created new Glorp Session '.

accessor := VWPoolingDatabaseAccessor forLogin: self appCtx login.

^(GlorpSession new)

accessor: accessor;

system: (AwkDescriptorSystem forPlatform: accessor platform);

useModificationTracker;

yourself

Should the VWPoolingDatabaseAccessor be a singleton?

Regards,

Bart

2010/9/11 Bart Veenstra <[hidden email]>

To bad I can't make it to Barcalona this yeah... I'll bet you all have a great time over there! Next year i'll definitly be at esug and / or Vegas :)

I will dedicate this weekend for getting Glorp sessions be maintained over a WASession.

@Sven, I will use you reddit application as a blue print and publish my findings over the weekend.

Regards,

Bart

2010/9/10 Alan Knight <[hidden email]>

In general, if you've got objects from different sessions, then yes, you're going to have to read it for the current session, or fake around it in interesting ways. It seems like the issue is why you're getting a different Glorp session for each Ajax request. I haven't looked at the details of the code, but I'm guessing that the mode it's operating in is that each http request is getting a separate glorp session and releasing it back to the pool again immediately, or just discarding it, and when an ajax request comes in it's being treated as a separate request, and getting a new session. So what you'd want to do is keep the Glorp session associated with the Seaside session, and re-use it for each request that comes in. You'd presumably want to make sure you're pooling the underlying database connections then, but that's fine. The details of that, and whether the framework already lets you do that are left as an exercise to the reader, as I'm in Barcelona enjoying myself prior to the start of ESUG :-)

At 02:27 PM 2010-09-10, Bart Veenstra wrote:

And another thing is bugging me during the development.

How do I cope with glorp objects that are stored in a WAComponent, like the current user, and use that when I update other glorp objects. It keeps pushing me a DuplicatePrimaryKeyException because the object is not in the current session. I need to reinstantiate the current user in the session with a database lookup, before I can use it again...

So, How to properly mix glorp objects coming from different sessions? This could be resolved, if the glorpFilter stays put in the WASession in each ajax request.

Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

Regards,

Bart

2010/9/10 Bart Veenstra <[hidden email] >

Hi,

I am working on an Ajax heavy application with Glorp as my mapping framework. I use the Glorp filter to assign a glorpSession to my database objects. This works pretty well, but it seems that for each request within the same session (like an jQuery ajax callback) a new GlorpSession is created.

When removing all sessions using WAAdmin clearAll, the Glorp Sessions still remain in the memory, (Checked with GlorpSession allInstances).

Should I worry about this? And how do I get rid of the GlorpSessions?

I tried GlorpSession allInstances do: [:each | each become:nil ] but the object is immutable...

Using VW 77 with the latest seaside from the public repository.

Regards,

Bart Veenstra

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

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
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

Bart Veenstra

Re: Glorp Sessions in ajax requests

In reply to this post by Boris Popov, DeepCove Labs (SNN)

I am using version 3 - 8.

2010/9/11 Boris Popov, DeepCove Labs (SNN) <[hidden email]>

Which version of Seaside-Glorp are you using? It works fine on VisualWorks w/o spawning new Glorp sessions.

-Boris (via BlackBerry)

From: [hidden email] <[hidden email]>
To: Seaside - general discussion <[hidden email]>
Sent: Sat Sep 11 04:12:04 2010
Subject: Re: [Seaside] Re: Glorp Sessions in ajax requests

To bad I can't make it to Barcalona this yeah... I'll bet you all have a great time over there! Next year i'll definitly be at esug and / or Vegas :)

I will dedicate this weekend for getting Glorp sessions be maintained over a WASession.

@Sven, I will use you reddit application as a blue print and publish my findings over the weekend.

Regards,

Bart

2010/9/10 Alan Knight <[hidden email]>

In general, if you've got objects from different sessions, then yes, you're going to have to read it for the current session, or fake around it in interesting ways. It seems like the issue is why you're getting a different Glorp session for each Ajax request. I haven't looked at the details of the code, but I'm guessing that the mode it's operating in is that each http request is getting a separate glorp session and releasing it back to the pool again immediately, or just discarding it, and when an ajax request comes in it's being treated as a separate request, and getting a new session. So what you'd want to do is keep the Glorp session associated with the Seaside session, and re-use it for each request that comes in. You'd presumably want to make sure you're pooling the underlying database connections then, but that's fine. The details of that, and whether the framework already lets you do that are left as an exercise to the reader, as I'm in Barcelona enjoying myself prior to the start of ESUG :-)

At 02:27 PM 2010-09-10, Bart Veenstra wrote:

And another thing is bugging me during the development.

How do I cope with glorp objects that are stored in a WAComponent, like the current user, and use that when I update other glorp objects. It keeps pushing me a DuplicatePrimaryKeyException because the object is not in the current session. I need to reinstantiate the current user in the session with a database lookup, before I can use it again...

So, How to properly mix glorp objects coming from different sessions? This could be resolved, if the glorpFilter stays put in the WASession in each ajax request.

Should I drop the glorp filter and put the glorp session in the WASession properties instance variable?

Regards,

Bart

2010/9/10 Bart Veenstra <[hidden email] >

Hi,

I am working on an Ajax heavy application with Glorp as my mapping framework. I use the Glorp filter to assign a glorpSession to my database objects. This works pretty well, but it seems that for each request within the same session (like an jQuery ajax callback) a new GlorpSession is created.

When removing all sessions using WAAdmin clearAll, the Glorp Sessions still remain in the memory, (Checked with GlorpSession allInstances).

Should I worry about this? And how do I get rid of the GlorpSessions?

I tried GlorpSession allInstances do: [:each | each become:nil ] but the object is immutable...

Using VW 77 with the latest seaside from the public repository.

Regards,

Bart Veenstra

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

--

Alan Knight [|], Engineering Manager, Cincom Smalltalk

[hidden email]

[hidden email]

http://www.cincom.com/smalltalk

_______________________________________________
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

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