[Seaside] Re: Let me see if I understand correctly...(more DB pool, application/session stuff).

[Rich Warren]

On Feb 27, 2006, at 4:34 AM, Yanni Chiu wrote:

<<much cut, some included below for reference>>

>
>> Ideally I would like to subclass the application and have the   
>> application itself manage the global resource--but that does not  
>> seem  to be a possibility within the seaside framework.
>
> Seaside doesn't appear to have it, because the Smalltalk environment
> already provides it.

No. As you describe it, Smalltalk gives me access to global variables  
(nothing revolutionary here). I'd always thought global variables  
were considered "bad form". I really don't see how Smalltalk's  
particular implementation changes this.

Being able to create instance members for the application has at  
least one real benefit. The instance variable can be automatically  
initialized and destroyed with the application. I can somewhat  
duplicate the same thing using lazy instantation of a singleton/ 
global/session class variable, but  (based on my understanding of  
your description and my experiments with singleton classes) the  
resources would still be locked into the singleton/global after the  
application closed, and would need to be discarded manually. This  
arguably amounts to a memory leak. I've also had problems getting my  
singleton class to let go of its copy of the instantated pool--so it  
would see my changes, but would not initialize new instance  
variables. This resulted in very confusing errors (at least for a  
Smalltalk beginner).

Most importantly, in my mind the seaside application Has-A database  
pool. This relationship implies that the pool should be an instance  
variable of the application object. All the other work-arounds just  
feel like hacks (more or less).

Having said that, making the pool a class instance member of the  
session feels like the best option to me. And the other concerns are  
probably not worth worrying about.

I would love to get more information about class pools. I've seen  
them mentioned several times (usually immediately followed by the  
sentence "...are beyond the scope of this article/tutorial."


>
>> Am I missing something, or thinking about this the wrong way?
>
> Yes, Smalltalk is a rich development environment. Take some time
> to explore it (look at tutorials and books that are freely available).

I know you're trying to help, and I thank you for that, but comments  
like this last one always upset me. It implies that I haven't read  
smalltalk books or done tutorials--which is completely untrue. I have  
done a lot of reading and searching on my own before posting here.  
Now if you have a specific reference that is pertinent to the topic  
at hand,  I would love to see it. But, none of the solutions we've  
discussed are specific to Smalltalk. Global variables, singleton  
classes (and variants), class variables: they're all standard OO  
features. Smalltalk being a "rich development environment" (though  
most certainly a true statement) does not really bear on the  
discussion at hand.

Anyway, thanks for your input.

-Rich-

> Here are a bunch of options for your connection pool:
>
> 1. Global connection pool instance.
>
> You can add your connection pool as a global using:
>     Smalltalk at: #DBConnectionPool put: MyConnectionPool new
> Then access it in your code using "DBConnectionPool"
>
> 2. Singleton
>
> Define a class variable and accessor in MyConnectionPool to hold
> the singleton instance, then access it using:
>     MyConnectionPool default
>
> 3. Class as singleton
>
> The class is already a global. Simply define all your connection
> pool methods on the class side. Then access your singleton using
> just "MyConnectionPool"
>
> 4. Class variable in MySession
>
> Add a class variable in MySession, maybe call it DBPool.
> Then within you session, access it using DBPool.
>
> There may be a bunch of other ways. One of them is class pools,
> but I'll leave the explanation of pros/cons of that approach
> to another time (or to someone else).