Re: ACL:AllegroCache philosophical question

On 2007-09-29 21:15:58 -0700, Ken Tilton <kennytilton@xxxxxxxxxxxxx> 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.


.

Relevant Pages

  • Re: ADO Connection Timeout
    ... so what happens when a connection failure forces one station to revert ... to a local database? ... Further, you *will* have contention issues, Jet does not support record ... to the central server, but you are willing to live with periods where it ...
    (microsoft.public.data.ado)
  • Re: ADO Connection Timeout
    ... When the first test is run, the results are stored in the central database. ... to the central server, but you are willing to live with periods where it ... i.e. a local database or even a text file. ... to function until the connection can be restored to the server. ...
    (microsoft.public.data.ado)
  • Re: ADO Connection Timeout
    ... to the central server, but you are willing to live with periods where it ... i.e. a local database or even a text file. ... to function until the connection can be restored to the server. ...
    (microsoft.public.data.ado)
  • Re: Communicating over the internet
    ... > That way you provide one manner in which to open the database, ... > can keep the connection open and then when someone wants to ... > server as the database and the soap dll connecting with a TCP socket. ... The name of the running program might help. ...
    (microsoft.public.vb.general.discussion)
  • Re: ADO Connection Timeout
    ... much rather write stored procedures and use server side cursors. ... local database, it is vital that I get the information to a central server. ... Once the connection is restored, ...
    (microsoft.public.data.ado)