[Seaside] How to add GLORP to a Seaside application?

Roger Whitney whitney at cs.sdsu.edu
Mon Jan 31 07:24:46 CET 2005


On Jan 30, 2005, at 8:48 AM, Martin J.Laubach wrote:

>   While trying to build a simple database based application with  
> Seaside, I tripped
> over the question how to do it so it would work as intended. I'm  
> trying to do it
> with GLORP, and the following problems arose:
>
>   In my main task do something like:
>
>   Problem #1:
>
> 	MyComponent>>go
> 		openDatabaseConnection.
> 		self call: mySubComponent.
> 		closeDatabaseConnection
>
>   If the user goes out for a coffee or closes his browser never to  
> return, the
> database connection stays open until, well, basically hell freezes  
> over. Not good,
> there are only that many connections possible. I probably need  
> something that gets
> executed as soon as the session times out. Wrapping the whole thing  
> with #ensure:
> does not seem to do the right thing, the ensure block is executed all  
> the time, not
> just when the #call: returns.
>
You could just open a connection for each session. The session will  
time out, so you can close the connection when the session ends. This  
will handle the case of the user going out to coffee. A connection per  
session will work only if the number of concurrent   connections your  
database will support is greater than the number of sessions that will  
be open at once. To create your own session subclass WASession. See  
http://www.eli.sdsu.edu/courses/fall04/cs683/notes/seasideLogin/ 
seasideLogin.html#a_Toc494861524 for an example.

If you are connecting to Postgres database creating connections is  
expensive, so you might what to use a connection pool. This makes using  
a connection per session a could be a problem as a session will hold a  
connection for a long time.

>
>   Problem #2:
>
> 	MySubComponent>>renderContentOn: html
> 		| t |
> 		db transact: [
> 			t := readObjectFromDatabase.
> 			html anchorWithAction: [ t setSomeField: 'somevalue' ].
> 			self commitTransaction ]
>
>   This quite obviously can't work, since the callback is invoked when  
> the
> transaction is already committed. When no transaction is in progress,  
> GLORP
> seems no to care for instanciated objects any more, so any change is  
> lost.
>
>
>   I arrived at a workaround that looks like
>
> 	MySubComponent>>renderContentOn: html
> 		| t |
> 		t := readObjectFromDatabase.
> 		html anchorWithAction: [ db transact:
> 			[ db refresh: t. t setSomeField: 'somevalue' ]].
>

refresh: will reread the object from the database. If you are not  
worried that the object has changed in the database you can use db  
registerAsOld: t. The object will not be read from the database, just  
registered with the session so changes to the object will be recorded  
in the database.
>   but that looks as if it will totally destroy performance and also  
> makes the
> whole exercise of using GLORP in the first place rather pointless --  
> when I
> have to re-register all objects with the database layer manually, I  
> might as
> well scribble manually to the database, avoiding GLORP alltogether.
>
I don't see how manually accessing tables via SQL will help. With read  
only data  I can read it in memory and keep it there as long as I want.  
If data can change keeping it in memory for a long time can result in  
consistency problems. What happens if your user takes 20 minutes to  
click on that link and someone else caused a change in that data?  
Unless you have some sort of write-through in memory cache of the  
database which all threads use the safest thing to do is to reread the  
data for each page request.

>   Are there any examples out there how to use glorp and Seaside  
> together?
> Or perhaps GLORP is the wrong thing to look at and it's completely  
> inappropriate?
>   Thanks,
>
> 	mjl
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>
>

----
Roger Whitney              Department of Computer Science
whitney at cs.sdsu.edu        San Diego State University
http://www.eli.sdsu.edu/   San Diego, CA 92182-7720
(619) 583-1978
(619) 594-3535 (office)
(619) 594-6746 (fax)



More information about the Seaside mailing list