Hi all I'm reading the AllegroCache docs, in particular the paper
titled "AllegroCache with Web Servers v1.0" (URL:
www.franz.com/products/allegrocache (scroll to AllegroCache
Documentation section))..
I need to do an (in)sanity check on database connections as they are
explained in the paper.
The example code creates an ac-map object, and it saves the database
connection (*allegrocache*) used to create the map in a global
variable. Great pains are then taken to restore a local binding of
*allegrocache* to the global variable whenever the map is accessed.
The paper contains this puzzling (to me) statement:
<quote>
*password-map* has an ac-map object as it's value. This value can only
be examined when *allegrocache* is bound to the database connection
from which the ac-map object was obtained.
</quote>
Surely I am misunderstanding the intent here. The above statement
implies that if I anticipate multiple database connections, I must
forever associate the connection with the set of database operations
performed on that connection. The example deals with only one object -
an ac-map. What if I connect to the database, create 1000 objects and
then do a commit. According to the above statement, I can only examine
those objects using the connection on which they were created.
I don't get it.
Can someone with a bigger brain than me please elucidate.
thanks.
John
jcb wrote:
> Hi all I'm reading the AllegroCache docs, in particular the paper titled
> "AllegroCache with Web Servers v1.0" (URL:
> www.franz.com/products/allegrocache (scroll to AllegroCache
> Documentation section))..
>
> I need to do an (in)sanity check on database connections as they are
> explained in the paper.
>
> The example code creates an ac-map object, and it saves the database
> connection (*allegrocache*) used to create the map in a global variable.
> Great pains are then taken to restore a local binding of *allegrocache*
> to the global variable whenever the map is accessed.
Well, that is the way specials are used. You start with not having to
forever indicate in a function call which DB you are using (tho several
AC functions /do/ take a :db keyword parameter, just to confuse things)
by having some stuff picked up from a special. Then you have to see to
it that that special is bound appropriately for what one is doing.
Nothing unusually onerous about that. And I would observe that one has
no more burden than one happens to be working on multiple DBs.
>
> The paper contains this puzzling (to me) statement:
>
> <quote>
> *password-map* has an ac-map object as it's value. This value can only
> be examined when *allegrocache* is bound to the database connection from
> which the ac-map object was obtained.
> </quote>
>
> Surely I am misunderstanding the intent here. The above statement
> implies that if I anticipate multiple database connections, I must
> forever associate the connection with the set of database operations
> performed on that connection.
As for reliably binding the special to the DB you are using, uh, again,
that is hardly onerous unless you are coding blindfolded and do not know
what things you are dealing with as you type. If that is the case, you
have bigger problems than dealing with AC.
What I thought was onerous was my whine to Franz (to whom you also
should be whining, not c.l.l), viz., doesn't a map or instance know to
which DB it belongs, and Franz conceded His Kennyness was correct but
that He was an Idiot but, oh, look, it suddenly works now, you do not
have to rebind *AC* to access an instance (including a map, which is an
instance of a persistent AC class), isnt Himself lucky?
So... the doc you cite might have been obsoleted by this recent
development, check with Franz.
> The example deals with only one object -
> an ac-map. What if I connect to the database, create 1000 objects and
> then do a commit. According to the above statement, I can only examine
> those objects using the connection on which they were created.
If I am not mistaken, you are objecting to the requirement that DB X be
used to get at things stored in DB X....hello?
>
> I don't get it.
>
> Can someone with a bigger brain than me please elucidate.
I think the problem is not brain-size so much as your admirable attempt
to understand a tool by reading about it. That puts you at the mercy of
technical writers, who combine an inability to program at all well with
an inability to write.
kt
--
http://www.theoryyalgebra.com/
"We are what we pretend to be." -Kurt Vonnegut
On 2007-09-29 21:15:58 -0700, Ken Tilton <···········@optonline.net> said:
>
>
> jcb wrote:
>> Hi all I'm reading the AllegroCache docs, in particular the paper
>> titled "AllegroCache with Web Servers v1.0" (URL:
>> www.franz.com/products/allegrocache (scroll to AllegroCache
>> Documentation section))..
>>
>> I need to do an (in)sanity check on database connections as they are
>> explained in the paper.
>>
>> The example code creates an ac-map object, and it saves the database
>> connection (*allegrocache*) used to create the map in a global
>> variable. Great pains are then taken to restore a local binding of
>> *allegrocache* to the global variable whenever the map is accessed.
>
> Well, that is the way specials are used. You start with not having to
> forever indicate in a function call which DB you are using (tho several
> AC functions /do/ take a :db keyword parameter, just to confuse things)
> by having some stuff picked up from a special. Then you have to see to
> it that that special is bound appropriately for what one is doing.
> Nothing unusually onerous about that. And I would observe that one has
> no more burden than one happens to be working on multiple DBs.
>
>>
>> The paper contains this puzzling (to me) statement:
>>
>> <quote>
>> *password-map* has an ac-map object as it's value. This value can only
>> be examined when *allegrocache* is bound to the database connection
>> from which the ac-map object was obtained.
>> </quote>
>>
>> Surely I am misunderstanding the intent here. The above statement
>> implies that if I anticipate multiple database connections, I must
>> forever associate the connection with the set of database operations
>> performed on that connection.
>
> As for reliably binding the special to the DB you are using, uh, again,
> that is hardly onerous unless you are coding blindfolded and do not
> know what things you are dealing with as you type. If that is the case,
> you have bigger problems than dealing with AC.
>
> What I thought was onerous was my whine to Franz (to whom you also
> should be whining, not c.l.l),
I posted here because I know from MANY years of lurking, Ken, that
c.l.l. is the #1 place to go when one needs a neutral, unbiased
discourse.
Plus the dudes at Franz tol' me that the main AC dude is traveling
presently, so I thought I'd have a shot at tossing it out to some folks
who have actually used the thing.
> viz., doesn't a map or instance know to which DB it belongs, and Franz
> conceded His Kennyness was correct but that He was an Idiot but, oh,
> look, it suddenly works now, you do not have to rebind *AC* to access
> an instance (including a map, which is an instance of a persistent AC
> class), isnt Himself lucky?
>
> So... the doc you cite might have been obsoleted by this recent
> development, check with Franz.
>
>> The example deals with only one object - an ac-map. What if I connect
>> to the database, create 1000 objects and then do a commit. According to
>> the above statement, I can only examine those objects using the
>> connection on which they were created.
>
> If I am not mistaken, you are objecting to the requirement that DB X be
> used to get at things stored in DB X....hello?
Hi.
No.
That's not what I'm objecting to, although as you say we're at the
mercy of tech writers. At this point I'm no longer sure what I'm
objecting to.
I think it's the rather confusing use of the term "database connection".
The docs state that you can open mulitple connections to the same
database, e.g. in a multithreaded environment. Cool!
They then state that you have to be careful not to confuse persistent
objects created on one database connection with objects created on
another connection (to the same database). In fact, they go on to
state that it's "even possible to have two different copies of the same
persistent object in the Lisp heap, each copy belonging to a different
connection."
That's not onerous?? So I connect, create a ton of objects and edit
some other ones, commit the transaction, and then I can't sync the
other connections up with this activity?? I'm all dude, wait...what??
They're connected to the same frikken database!
Connections to *different* databases, yeah I can see that; makes perfect sense.
Unnnnnnnnnnnnnnnnnnnnnngh.
>
>>
>> I don't get it.
>>
>> Can someone with a bigger brain than me please elucidate.
>
> I think the problem is not brain-size so much as your admirable attempt
> to understand a tool by reading about it. That puts you at the mercy of
> technical writers, who combine an inability to program at all well with
> an inability to write.
>
> kt
Yeah. Keep hope alive, that's my motto.
Well...thanks for trying to explain it, anyway. Im'a whine to Franz
like you said. Maybe somebody else there knows.
J.
It just means that your database has to have a good housekkeeper and a
very good transaction monitoring system.
Cor
--
(defvar MyComputer '((OS . "GNU/Emacs")(IPL . "GNU/Linux")))
If all fails to satisfy you read the HyperSpec or info woman
http://www.clsnet.nl/wav/peace.wav
http://www.clsnet.nl/mail.php
Figured it out...
Docs are referring to transient objects vs. persistent objects.
Thanks again Ken - I was being facetious but I meant it in a good way :)
On 2007-09-29 21:15:58 -0700, Ken Tilton <···········@optonline.net> said:
>
>
> jcb wrote:
>> Hi all I'm reading the AllegroCache docs, in particular the paper
>> titled "AllegroCache with Web Servers v1.0" (URL:
>> www.franz.com/products/allegrocache (scroll to AllegroCache
>> Documentation section))..
>>
>> I need to do an (in)sanity check on database connections as they are
>> explained in the paper.
>>
>> The example code creates an ac-map object, and it saves the database
>> connection (*allegrocache*) used to create the map in a global
>> variable. Great pains are then taken to restore a local binding of
>> *allegrocache* to the global variable whenever the map is accessed.
>
> Well, that is the way specials are used. You start with not having to
> forever indicate in a function call which DB you are using (tho several
> AC functions /do/ take a :db keyword parameter, just to confuse things)
> by having some stuff picked up from a special. Then you have to see to
> it that that special is bound appropriately for what one is doing.
> Nothing unusually onerous about that. And I would observe that one has
> no more burden than one happens to be working on multiple DBs.
>
>>
>> The paper contains this puzzling (to me) statement:
>>
>> <quote>
>> *password-map* has an ac-map object as it's value. This value can only
>> be examined when *allegrocache* is bound to the database connection
>> from which the ac-map object was obtained.
>> </quote>
>>
>> Surely I am misunderstanding the intent here. The above statement
>> implies that if I anticipate multiple database connections, I must
>> forever associate the connection with the set of database operations
>> performed on that connection.
>
> As for reliably binding the special to the DB you are using, uh, again,
> that is hardly onerous unless you are coding blindfolded and do not
> know what things you are dealing with as you type. If that is the case,
> you have bigger problems than dealing with AC.
>
> What I thought was onerous was my whine to Franz (to whom you also
> should be whining, not c.l.l), viz., doesn't a map or instance know to
> which DB it belongs, and Franz conceded His Kennyness was correct but
> that He was an Idiot but, oh, look, it suddenly works now, you do not
> have to rebind *AC* to access an instance (including a map, which is an
> instance of a persistent AC class), isnt Himself lucky?
>
> So... the doc you cite might have been obsoleted by this recent
> development, check with Franz.
>
>> The example deals with only one object - an ac-map. What if I connect
>> to the database, create 1000 objects and then do a commit. According to
>> the above statement, I can only examine those objects using the
>> connection on which they were created.
>
> If I am not mistaken, you are objecting to the requirement that DB X be
> used to get at things stored in DB X....hello?
>
>>
>> I don't get it.
>>
>> Can someone with a bigger brain than me please elucidate.
>
> I think the problem is not brain-size so much as your admirable attempt
> to understand a tool by reading about it. That puts you at the mercy of
> technical writers, who combine an inability to program at all well with
> an inability to write.
>
> kt