- Zope - Zope lists

action modifier adds calling method to URL?
by Milos Prudek 02 Nov '01

02 Nov '01

I have a method "run" that is called from method "display" on /presley/elvis folder. When using simple form as follows... <form action="run"> <input type="submit" name="submit" value="Run!"> </form> ... it goes to a correct URL: /presley/elvis/run ... and URL0 is /presley/elvis/run However, I'd like to use :action modifier, as follows: <form action=""> <input type="submit" name="run:action" value="Run!"> <input type="submit" name="set:action" value="Set!> </form> This works fine, but it goes to: /presley/elvis/display/run or /presley/elvis/display/set. and URL0 is also /presley/elvis/display/run or /presley/elvis/display/set. This '/display/' disturbs logic of my program (things like PARENTS). Is this standard behaviour, or a Zope fault? If it's standard, what is the advantage of this behaviour? -- Milos Prudek

2 2

RE: [Zope] zope operations atomic?
by Kapil Thangavelu 02 Nov '01

02 Nov '01

--- Clark OBrien <COBrien(a)isis-server.vuse.vanderbilt.edu> wrote: > > > > > Thanks for the clarification - more comments below. > clark > no problem. one clarification to my clarification:), zope threads do not maintain persistent connections to the zodb, they open a new connection for every request, the zodb internally stores connection objects (and associated caches) in a LIFO stack to maximize cache hits. i'm actually a little unclear when the these connections are synced up with the db (cache invalidated). > >each thread maintains its own connection to the > zodb, and each connection > >mantains its own cache. when you load up on object > you are not deep > loading, > >your loading up all of that object's data minus any > persistent attributes > it > >might have. so in a given folder stuffed with > standard zope objects you > only > >load up that folders attributes unless you > explicitly access the other > >peristent objects. objects get stuffed into cache > after access, for faster > >lookups. as chris mentioned zope treats every web > request as a transaction. > > >when a thread tries to commit an object it, the db > checks to see if it has > >been updated since the transaction began, in which > case you get a conflict. > > >so what does atomic mean, that a given set of > operations either succeeds as > a > >whole or fails. the zodb passes this standard. the > issue you seem to layout > > >below is that your more comfortable with explicit > locking... > > atomic implies a set of opperations succeed or they > have no effect on the > data. > > > suppose I have a method AtoB that changes every > letter A to B. > suppose I have another method BtoC that changes the > leter B to C. > > what is the outcome of invoking these methods in > different thread contexts > on the > string ABABABAB? > it depends on the concurrency. if both methods execute concurrently, than one will conflict and one will commit from trying to write on the same object. which one is hard to determine apriori... i'm taking a wild guess that it would be first one to commit. Chris, could you comment on this? but what does this mean in terms of atomic operation? independently running these methods in different contexts implies that these each forms a separate atomic operation with the additional set of operations in each context respectively. so each operation will either succeed or fail, if their is no consistency check made on the value of the string, than its possible to achieve different values depending on timing. the "loser" will retry, but in either case the operations are still atomic in that they succeed or fail. to take a page from chris's rdbms analogy. an rdbms app might get around this by explicitly locking the row. so you could know the value of the string assuming you know the timings of the threads, and which one gets to the lock first. but unless you define a consistency check, you're at the mercy of the thread timings, which is a poor way to determine consistency for concurrent operations. > > >your joking, right... besides the fact that > excessive locking kills > >performance and scalability, i *know* i don't want > to have to litter my > code > >with locks and thinking about concurrency. the zodb > greatly mitigates > >concurrency issues, making them almost non-existent > for most code. moving > >from this paradigm to some application level > locking paradigm greatly > >complicates code and would make it damm near > impossible to be productive > with > >zope, IMO. > > No I am not joking, resolving conflicts after each > request by simply > rolling back is easy to implement. > The problems with concurrent access are with finding > *intelligent* solutions > not easy solutions. The zope guys were smart and > realized that it is only > rarely > that a web application has to deal with concurrent > access and when this > happens > it should be done at the db layer- as the word > "optimistic" implies. concurrent write access that is. as i said previously in the unquoted material that made up my previous reply, if you're application has a lot of concurrent write operations, i would store the data in an rdbms. > also making manage_changeProperties atomic would be > an the level of C making > strcpy threadsafe. unless you are doing embedded > systems you appreciate such > features. lost me here. cheers kapil > > > -----Original Message----- > > From: kapil thangavelu > [mailto:kthangavelu@earthlink.net] > > Sent: Wednesday, October 31, 2001 3:03 AM > > To: Clark OBrien; 'zope(a)zope.org' > > Subject: Re: [Zope] zope operations atomic? > > > > On Wednesday 31 October 2001 07:11 am, Clark > OBrien wrote: > > > Hi: > > > I cannot find documentation that would tell me > how zope manages thread > > > synchronization > > > > nutshell version. > > > > zope uses optimistic conflict resolution, no > application level locking > > takes > > place, because all threads have their own object > spaces. only on > > commits, is > > there some synchronization (deep within the zodb) > to insure that there > > weren't conflicts, if so a conflict error is > raised, and the request > > gets > > retried. applications can define their own > conflict resolution, see the > > zodb > > wikis and zope developer's guide for more details. > > > > kapil > > > > _______________________________________________ > > Zope maillist - Zope(a)zope.org > > http://lists.zope.org/mailman/listinfo/zope > > ** No cross posts or HTML encoding! ** > > (Related lists - > > > http://lists.zope.org/mailman/listinfo/zope-announce > > http://lists.zope.org/mailman/listinfo/zope-dev ) __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com

2 3

a manage_workspace of my own
by Jerry McRae 02 Nov '01

02 Nov '01

Hi zope, My application uses lots of different types of tables. What I would really like is a custom public manage_workspace interface to my folders. I want the cut/copy/paste and 'add' buttons. I just need the options to: 1) set my own tabs 2) create my own 'types' for the pull-down add box 3) add a column or two 4) limit and/or sort the contents I have looked all over and I cannot figure out how to inherit the manage_workspace logic with a different name and parameters. This seems an obvious interface for certain applications, but no one has mentioned it in the list or the how-to's. Being good with logic, average with Python, and abeginning Zope programmer, where would I even start? --Jerry Zope 2.4.1 ( ) / History repeats itself, and that's one of the things that's wrong with history. --Clarence Darrow

1 1

RE: [Zope] zope operations atomic?
by Clark OBrien 02 Nov '01

02 Nov '01

I will convert my example to code and post the results. I did not understand case b). In particular what does "ghost out" mean. -----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com] Sent: Thursday, November 01, 2001 2:01 PM To: Clark OBrien Cc: 'k_vertigo(a)yahoo.com'; 'zope(a)zope.org' Subject: Re: [Zope] zope operations atomic? Clark OBrien wrote: > It is what happens with this retrying that interests me. As the example > given > below shows, this retry may never succeed. Thus long running operations may > never complete and are effectively starved by faster running operations. > > > > Assume in Zope I have a folder structure like this. > > Folder-1 > -Folder-2 > -Folder-3 > .... > .. > Folder-1000 > > > Suppose I have a script traverseFolder(root) that starts at a given root and > traverses sub-folders adding the attribute foo. > > If I continuously call traversefolder(Folder-1000) how could > traverseFolder(Folder-1) ever complete. I mean, by the time > traverseFolder(Folder-1) could complete traverseFolder(Folder-1000) would > have already committed several times. What would happen with the request > that started traverseFolder(Folder-1), would it keep being retried ad > infinitum. > It is basically starved out of contention by a faster running operations. It does get interesting when you consider that the longer-running transaction might always tend to lose on read conflicts because: a) read conflicts can't be resolved. b) the longer-running transaction *might* "ghost out" Folder-1000 to conserve RAM during the traversal after the first (aborted) commit. If b) is true in your example for every run of traverseFolder(Folder-1), your contention that it will never commit might prove correct. It'd be slightly interesting to try it to see what the behavior actually is. Would you be willing to do so? In any case, we have an answer to this problem if you're willing to lose a bit of consistency. CoreSessionTracking's LowConflictConnection class comes in handy here. If your application is very write-intensive and you've carefully coded a massive hotspot ala your example into it, you can turn off read conflicts by using this class at the expense of some consistency. With read conflicts turned off, I'm positive your example will eventually resolve itself. Maybe it'll take a few minutes of retries, but it will eventually finish. I say that because the longer running of the two scripts will eventually be able to do the commit because it's statistically as likely to "win" a commit as the shorter-running script when there's a write conflict; it just has fewer opportunities to do so. And actually if you used a special FooFolder instead of a Folder for this demonstration, the only thing that changed was foo, and the value of foo was often the same in both connections on the object upon which the transaction conflicted, you could resolve most of the conflicts that could potentially occur here (save for the read conflicts) by giving it a _p_resolveConflict that looked something like this: class FooFolder: def _p_resolveConflict(self, old, saved, new): marker = [] for k,v in saved.items(): if new.get(k, marker) != v: return None for k,v in new.items(): if saved.get(k, marker) != v: return None return new However, the real answer is: Dont design your application like this if you can help it. This is not a good pattern. It's best to avoid hotspots like Folder-1000 in your example. It's no different than continually beating the snot out of a field in a row in a relational database table with writes from multiple threads, where one of the threads is running an overnight transaction and the others are just incrementing the field every second. You have the same consistency, contention, and timeliness issues there, AFAICT, except that it's expressed in terms of pages, locks, and dirty reads. (I'm sure there's an Oracle person waiting around to "WRONG!" me to death, however. ;-) - C

3 3

Conflict Errors
by Richard Jones 02 Nov '01

02 Nov '01

Here I was I thought Conflict Errors only happen during writes, but I'm getting conflict errors in the strangest places: /home/zope/Zope/lib/python/Products/PageTemplates/Expressions.py line 332: o=object[name] inside our code, in a sorting function: return cmp(getattr(x, attribute), getattr(y, attribute)) Now these are "just" attribute/member accesses .. the objects holding the attributes (ie. "object", "x" and "y") are PropertyManagers and ObjectManagers. Anyone have any hints? Richard

3 7

RE: [Zope] What is Error(200)?
by Stuart Nicholson 01 Nov '01

01 Nov '01

I believe that this may be caused by the pcgi wrapper binary timing out. Presumably you're running Zope through pcgi? And presumably your reporting operation takes some time. I am not an expert but you'll also see this message if Zope chokes for some reason (for example I see this occasionally if the back end relational DB I'm using isn't running). I suspect you'll have to modify the pcgi wrapper source to increase the timeout? Stuart Nicholson Software Engineer wirelessdata - making data fly DDI (09) 306 3935 FAX (09) 379 7360 -----Original Message----- From: Steven Grimes [mailto:sgrimes@atinucleus.com] Sent: Friday, 2 November 2001 12:27 p.m. To: Zope Subject: [Zope] What is Error(200)? I'm trying to run a rather large report and The report writes a couple of files to the disk and should report and should display a summary and links to the files on screen. The report writes the two files but all it returns to the browser is the following: ! Temporarily Unavailable The resource you requested is temporarily unavailable - please try again later. (107) bad stdout strlen (0) This is the source of the browser page: <HTML> <HEAD> <TITLE>Temporarily Unavailable</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <TABLE BORDER="0" WIDTH="100%"> <TR> <TD WIDTH="10%"> <CENTER> <B><FONT SIZE="+6" COLOR="#77003B">!</FONT></B> </CENTER> </TD> <TD WIDTH="90%"><BR> <FONT SIZE="+2">Temporarily Unavailable</FONT> <P> The resource you requested is temporarily unavailable - please try again later. </TD> </TR> </TABLE> (107) bad stdout strlen (0)  </BODY></HTML> When I look at the Debug screen I see the following: 2001-10-30T19:02:45 ERROR(200) ZServer uncaptured python exception, closing channel <PCGIChannel at 18678a0> (socket.error:(10053, 'winsock error') [C:\Program Files\ATIAnywhere\ZServer\medusa\asynchat.py|initiate_send|211] [C:\Program Files\ATIAnywhere\ZServer\medusa\asyncore.py|send|274]) Any ideas about what could be causing this? I'm running Zope 2.2.0 on Windows NT4 sp5 through IIS 4 and PCGI. Thanks, Steven Grimes Database Engineer sgrimes(a)atinucleus.com Accelerated Technology, Inc. 720 Oak Circle Drive East Mobile, AL 36609 www.acceleratedtechnology.com *Please note new area code "251" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Over Ten Years of Providing Embedded Solutions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Zope maillist - Zope(a)zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) ---------------------------------------------------------------------- The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorised to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. Wirelessdata Ltd is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt. ----------------------------------------------------------------------

1 0

zodb installation
by Clark OBrien 01 Nov '01

01 Nov '01

How do I use zodb outside of zope. I saw a document that said I need to add some files to a path or something but I don't remember what and I cant find the doc

5 5

What is Error(200)?
by Steven Grimes 01 Nov '01

01 Nov '01

I'm trying to run a rather large report and The report writes a couple of files to the disk and should report and should display a summary and links to the files on screen. The report writes the two files but all it returns to the browser is the following: ! Temporarily Unavailable The resource you requested is temporarily unavailable - please try again later. (107) bad stdout strlen (0) This is the source of the browser page: <HTML> <HEAD> <TITLE>Temporarily Unavailable</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF"> <TABLE BORDER="0" WIDTH="100%"> <TR> <TD WIDTH="10%"> <CENTER> <B><FONT SIZE="+6" COLOR="#77003B">!</FONT></B> </CENTER> </TD> <TD WIDTH="90%"><BR> <FONT SIZE="+2">Temporarily Unavailable</FONT> <P> The resource you requested is temporarily unavailable - please try again later. </TD> </TR> </TABLE> (107) bad stdout strlen (0)  </BODY></HTML> When I look at the Debug screen I see the following: 2001-10-30T19:02:45 ERROR(200) ZServer uncaptured python exception, closing channel <PCGIChannel at 18678a0> (socket.error:(10053, 'winsock error') [C:\Program Files\ATIAnywhere\ZServer\medusa\asynchat.py|initiate_send|211] [C:\Program Files\ATIAnywhere\ZServer\medusa\asyncore.py|send|274]) Any ideas about what could be causing this? I'm running Zope 2.2.0 on Windows NT4 sp5 through IIS 4 and PCGI. Thanks, Steven Grimes Database Engineer sgrimes(a)atinucleus.com Accelerated Technology, Inc. 720 Oak Circle Drive East Mobile, AL 36609 www.acceleratedtechnology.com *Please note new area code "251" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Over Ten Years of Providing Embedded Solutions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0

zope operations atomic?
by Clark OBrien 01 Nov '01

01 Nov '01

It is what happens with this retrying that interests me. As the example given below shows, this retry may never succeed. Thus long running operations may never complete and are effectively starved by faster running operations. Assume in Zope I have a folder structure like this. Folder-1 -Folder-2 -Folder-3 .... .. Folder-1000 Suppose I have a script traverseFolder(root) that starts at a given root and traverses sub-folders adding the attribute foo. If I continuously call traversefolder(Folder-1000) how could traverseFolder(Folder-1) ever complete. I mean, by the time traverseFolder(Folder-1) could complete traverseFolder(Folder-1000) would have already committed several times. What would happen with the request that started traverseFolder(Folder-1), would it keep being retried ad infinitum. It is basically starved out of contention by a faster running operations. -----Original Message----- From: Chris McDonough [mailto:chrism@digicool.com] Sent: Thursday, November 01, 2001 11:16 AM To: Kapil Thangavelu Cc: Clark OBrien; 'Chris McDonough'; zope(a)zope.org Subject: Re: [Zope] zope operations atomic? AFAIK, a read conflict is raised in this circumstance, so there can't be a dirty read. But again, since requests which raise conflicts are retried, there is never a consistency problem. - C Kapil Thangavelu wrote: > even more generally the problem can be stated as > transaction A starts reads a bunch of objects, > transaction B starts and will read a set of objects > that intersects with transaction A. transaction A > commits changing objects that B is about to read > (after B has read some objects). B finishes, and has > possibly commited or done operations on data that is > no longer in sync because the set of data may not have > been consistent for its operation, hence the dirty > read. > > this is a more interesting and IMO legitimate concern, > i haven't done any testing recently, but i believe as > it currently stands this should throw a ConflictError > (i'm not sure, though.). Jim and pythonlabs have > talked about setting up some sort MVCC for the zodb, > whereby transaction B will see a snapshot of objects > as it existed when it began. if you're interested in > this further i would send mail to the > zodb-dev(a)zope.org list, referencing this thread. > > cheers > > kapil > > --- Clark OBrien > <COBrien(a)isis-server.vuse.vanderbilt.edu> wrote: > >>Here is the example I was thinking about. >> >> >>1) Suppose an online store is selling product X and >>at a >>given moment its inventory is n. Two shoppers hit >>the buy >>button at about the same time. >> >>Then either: >> >>a) No conflict is detected because both threads set >>the inventory >>value to the same value, n-1. This would cause a >>problem if n = 1 >> >>Or: >>b) A conflict is detected when the last thread >>writes because the inventory >>is not >>n as it was when he read it. request is resubmitted >>but again another thread >>has >>changed made the value dirty- thread starves. >> >> >> >> >> >> >> >> >> >> >>-----Original Message----- >>From: Chris McDonough [mailto:chrism@zope.com] >>Sent: Thursday, November 01, 2001 6:50 AM >>To: Clark OBrien; k_vertigo(a)yahoo.com; zope(a)zope.org >>Subject: Re: [Zope] zope operations atomic? >> >> >>What is "the dirty read problem"? >> > > > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > -- Chris McDonough Zope Corporation http://www.zope.org http://www.zope.com "Killing hundreds of birds with thousands of stones"

3 2

(no subject)
by wayne_connolly＠yahoo.com 01 Nov '01

01 Nov '01

Hi, I have some javascript validation for email adresses ect(just standard ones, and they are placed in the head of my standard header. They work outside of zope but not inside. Is there something im doing wrong(i am the zope admin). all code is in http://www.teenagepro.com (my band)index_html page but is not working. Please help me. Wayne ===== (`'·.¸(`'·.¸'Ô'¸.·'´)¸.·'´) «´·.¸¸.·´£A¥GØ´·.¸¸.·`» www.wayneconnolly.com «¸.·´`·(¸.·-·.¸)·´`·.¸» (¸.·'´(¸.·'´ `'·.¸)`'·.¸)

1 0