[Seaside] Re: Glorp Sessions in ajax requests

[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 <bart.veenstra at gmail.com>

> 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 <knight at acm.org>
>
>  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 <bart.veenstra at gmail.com >
>>
>>  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
>> seaside at lists.squeakfoundation.org
>>  http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>> --
>> Alan Knight [|], Engineering Manager, Cincom Smalltalk
>> knight at acm.org
>> aknight at cincom.com
>>  http://www.cincom.com/smalltalk
>>
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20100911/39c28789/attachment-0001.htm