Re: ACL:AllegroCache philosophical question



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
.

Relevant Pages

  • ACL:AllegroCache philosophical question
    ... Hi all I'm reading the AllegroCache docs, in particular the paper titled "AllegroCache with Web Servers v1.0" ).. ... The example code creates an ac-map object, and it saves the database connection used to create the map in a global variable. ... 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. ...
    (comp.lang.lisp)
  • Re: ACL:AllegroCache philosophical question
    ... titled "AllegroCache with Web Servers v1.0" ).. ... The example code creates an ac-map object, and it saves the database connection used to create the map in a global variable. ... that is the way specials are used. ... 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. ...
    (comp.lang.lisp)