[Seaside] Re: Let me see if I understand correctly...(more DB
pool, application/session stuff).
rwmlist at gmail.com
Mon Feb 27 21:05:57 UTC 2006
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
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.
> 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).
More information about the Seaside