Re: [Zope-dev] thread locking and ZODB

2001-09-11 Thread Chris Withers 

Terry Kerr wrote:
> 
> I have a method which increments an attribute on the current object.  I
> have created a thread lock so that multiple threads accessing the method
> simultaneously cannot stuff up the attribute value:

The ZODB doesn't work like that ;-)
As I understand it, each DB connection gets it's own consistent copy of the ODB,
so you don't need to worry about locking...

> def nextOrderNumber(self):
> lock.acquire()
> self._order_number = self._order_number + 1
> lock.release()
> return str(self._order_number)
> 
> My concern is that even though a second thread is halted at
> "lock.acqure()" while the first thread updates the order_number, that
> the second thread has an 'out of date' version of 'self' with the
> original order_number value in it, hence, is still returning the
> incorrect order_number.

Indeed. The is called conflict resolution and your problem is solved as an
example in:
http://www.zope.org/Documentation/Articles/ZODB2
...in the section "Resolving Conflicts"

Personally, I'd use a file-based counter or auto incrementing sequel column.

cheers,

Chris

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

[Zope-dev] thread locking and ZODB

2001-09-11 Thread Terry Kerr 

Hi,

I have a method which increments an attribute on the current object.  I
have created a thread lock so that multiple threads accessing the method
simultaneously cannot stuff up the attribute value:

lock = thread.allocate_lock()

def nextOrderNumber(self):
lock.acquire()
self._order_number = self._order_number + 1
lock.release()
return str(self._order_number)

My concern is that even though a second thread is halted at
"lock.acqure()" while the first thread updates the order_number, that
the second thread has an 'out of date' version of 'self' with the
original order_number value in it, hence, is still returning the
incorrect order_number.

Do I need to explicity get the order_number attribute from the ZODB
somehow, rather than grabbing it from 'self'?

terry

-- 
Terry Kerr ([EMAIL PROTECTED])
Bizar Software Pty Ltd (www.bizarsoftware.com.au)
Phone: +61 3 9563 4461
Fax: +61 3 9563 3856
ICQ: 79303381

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Re: Collector down - status and potential help request

2001-09-11 Thread Steve Alexander 

Ken Manheimer wrote:

> I was wrong - the collector csv dumps apparently did not include the
> *body* of the items, which is, um, important.  We're nearly back to square
> one on recovering the old issues.  Aargh.


I've got the following Collector items from the google cache:

374
375
386
476
645
718
736
796
842
860
871
892
894
916
919
939
945
954
995
1002
1005
1014
1028
1049
1056
1059
1066
1102
1103
1112
1134
1156
1158
1159
1179
1183
1194
1195
1204
1219
1220
1228
1257
1260
1270
1279
1298
1328
1360
1364
1371
1388
1409
1413
1441
1442
1445
1457
1480
1540
1541
1542
1551
1566
1570
1586
1606
1629
1687
1737
1768
1772
1797
1848
1884
1892
1928
2022
2120
2183
2200
2205
2254
2410
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2468

I'll throw something together to get the important data out.

Ken, perhaps you can list the important fields that are going to be put 
into a new Collector, so that anyone helping out uses the same ordering 
/ field-names.

--
Steve Alexander
Software Engineer
Cat-Box limited


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Problems with CatalogAware?

2001-09-11 Thread Toby Dickenson 

On Mon, 10 Sep 2001 09:40:46 -0700, [EMAIL PROTECTED] wrote:

>def manage_addAdItem(self, id, title, REQUEST=None):
> """Zope managment interface create method for AdItem"""
>
> ad=AdItem(id)
I assume the __init__ of AdItem that sets the default values that you
mentioned

> ad.setId(id)
> ad.setTitle(title)
> if REQUEST is not None:
>   ad.setAdBody(REQUEST['adBody'])
>   if (len(REQUEST['keywords']) > 0):
> ad.setKeys(REQUEST['keywords'])
>   ad.setAdDateMulti(=REQUEST['Ad'], mm=REQUEST['Admm'],
>dd=REQUEST['Addd'])
>   ad.setRtDateMulti(=REQUEST['Rt'], mm=REQUEST['Rtmm'],
>dd=REQUEST['Rtdd'])
>   ad.featureURL=REQUEST['featureURL']
You overwrite all the defaults with the real values... .good.

> self._setObject(id, ad)
You add the new object to the folder. The folder calls
ad.manage_afterAdd (or whatever its called), which in the case of
CatalogAware calls index_object.

Everything looks right to me. The catalog should contain the real
values.



Toby Dickenson
[EMAIL PROTECTED]

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Getting Unauthorized from __bobo_traverse__.

2001-09-11 Thread Erik Enge 

[Erik Enge]

|   def index_html(self):
|   """we have a doc string"""
|   return DTMLFile('index_html', globals())
| 
| And that worked [...]

Actually it doesn't.  Don't know why I thought it did.

This however does work:

   index_html__roles__ = ['Manager']
   def index_html(self):
   """we have a doc string"""
   return DTMLFile('index_html', globals())
 
There's something here I don't understand.  My __bobo_traverse__
raises an unauthorized:

def __bobo_traverse__(self, REQUEST, name):
"""Intercept the traversal"""
if name:
if hasattr(self, name):
return getattr(self, name)

self = 
REQUEST = the correct mapping object
name = 'index_html'

If I comment the __bobo_traverse__ away, the one in Application.py is
used:

def __bobo_traverse__(self, REQUEST, name=None):
try: return getattr(self, name)
except AttributeError: pass
[snip]

I've snipped it, because in this case getattr() always works.

self = 
REQUEST = the correct mapping object
name = 'account'

And this one doesn't raise an Unauthorized (and the name is different
- maybe there is traversal going on elsewhere too?).

Anyone "been there done that" before?

Thanks in advance. :)

___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )