hi joseph, wow, that email, was a blast from the past. the best thing would be to add to a conflict resisistant container type like a btree and manually call commit at set intervals through the processing, deactivating objects via _p_deactivate as they get added to the container (to lessen mem requirements and assuming their persistent derived objects). keep in mind that there will be extra size growth for the storage if you're using a non packless variant. quick example (untested) count = 0 thresh = 1000 for x in really_big_data_set:     if count%thresh == 0:         get_transaction().commit()     container.add_object(count, x)     x._p_deactivate() this runs minor interference with the zope semantics, which will try to commit the txn at the end of the request, but that shouldn't cause any operational difficulties. hth, feel free to elaborate if that you need more info. cheers kapil On Wednesday 16 January 2002 09:40 pm, Joseph Wayne Norton wrote:

Kapil -

I have been doing some searching through some of the zope mail archives and the zope.org site. I ran across the following e-mail (quite old) from you ...

http://zope.nipltd.com/public/lists/zope-archive.nsf/242bb7cc2b2c343d802568 ab003585d4/6a900d1f029e6ef38025693600744914?OpenDocument

I'm wondering if you have any further updates on the above subject. I have a similar requirement.

I would like to be able to perform 1 or more "checkpoints" within a single zope request. If the request transaction is aborted, then only changes since the most recent "checkpoint" should be rolledback.

Any ideas or suggestions?

- j

_______________________________________________ Zope maillist - Zope@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 )