Hi again, Boring, Jeff W, ALBAS wrote: > Thomas: > > >>There is also a sample for this in our test cases. < > > > Sorry, can't find it. Which one? > org.apache.ojb.odmg.LockTestUncommitedReads does not seem to be it. >
o.a.ojb.broker.OptimisticLockingTest > >>Locking is needed on the ODMG level not to trigger locking on the db, > > but to register objects to the ODMG transaction mechanism. Thus you > still have to lock objects to your ODMG transaction even if with OL. < > > I learned from an earlier thread here that OJB.ODMG locking is needed to > manage concurrency in the object cache, concurrency is not managed against the cache, but against a table of object identities. Thus locking is independend of the cache and does also work across multiple VMs (if a persistent locktable is used). > not the underlying db. > But this > architecture assumes that all applications/access are using OJB.ODMG. to participate in *pessimistic* tx management, yes. > Since this is not the case in our environment, I don't believe we can > use the object cache in OJB. OL works in spite of the cache. OL is meant to synchronize cached apps against the database. If you don't want to use the cache just tell OJB to use the EmptyObjectCacheImpl in OJB.properties. >Would we have to still have to lock objects > with OL even though we will not be using the cache? Why? Yes, because locking objects to an ODMG tx is the only way to tell the tx that it must track this object. As mentioned above: if you don't want to use the cache, set up the EMptyCacheImpl. ODMG transaction management will work as normal, as locking does not rely on the cache. cheers, Thomas > Jeff > > -----Original Message----- > From: Thomas Mahler [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 07, 2002 3:29 PM > To: OJB Users List > Subject: Re: PersistenceBroker or ODMG? > > > > > Boring, Jeff W, ALBAS wrote: > >>>I agree. I also don't like ODMG OQL. Thus I implemented the ODMG query >> >>layer in a way that allows to use the much handier PB QUeries also >>inside OJB ODMG apps. (See the faq.html for more details).< >> >>Thomas, I read the FAQ (repeated below) but I am concerned about the >>last sentence. I know you are using OBJ.PB optimistic locking on one > > of > >>your projects (os390, db2, websphere & ojb). Can you explain 1) the >>basic approach to using OJB.PB optimistic locking within a OJB.ODMG >>based application [and/or point me to a specific example] > > > You have to define optimistic locking (OL) with a timestamp or a version > > attribute. > (http://jakarta.apache.org/ojb/repository.html#field-descriptor) > There is also a sample for this in our test cases. > > You have to set the ODMG lock level to "read-uncommitted", which is the > default for the whole repository. > > >>and 2) what >>relevance the last sentence has in this context? Thanks, >> > > Locking is needed on the ODMG level not to trigger locking on the db, > but to register objects to the ODMG transaction mechanism. Thus you > still have to lock objects to your ODMG transaction even if with OL. > > cheers, > Thomas > > >>The ODMG implementation relies on PB Queries internally! Several users >>(including myself) are doing this. If you have a look at >>org.apache.ojb.odmg.oql.OqlQueryImpl.execute() you will see how OJB >>Query objects can be used withing ODMG transactions. The most > > important > >>thing is to lock all objects returned by a query to the current >>transaction. >> >>Jeff >> >>-----Original Message----- >>From: Thomas Mahler [mailto:[EMAIL PROTECTED]] >>Sent: Saturday, October 05, 2002 3:25 PM >>To: OJB Users List >>Subject: Re: PersistenceBroker or ODMG? >> >> >>Hi again Jason, >> >>Jason Mihalick wrote: >> >> >>>Thomas, >>> >>>1. Thanks for clarifying the optimistic locking support. >>>2. Clarification on the internal tables is an example of where the >>>documentation could be better. Is there documentation anywhere that >>>specifies what "special features" you mention that require the >> >>internal >> >> >>>tables and how to disable the need for the internal tables? >> >> >>our platforms.html document explains each of the internal tables. As > > no > >>one ever requested to use OJB without these tables there is no special > > >>advice on how to do so. I will add respective note. >> >> >> >>>When I read the >>>deployment documentation I thought it said to ensure that those tables >>>existed. I'd check the doc now, but for some reason all of >>>http://jakarta.apache.org is down. >>> >> >> >>The documentation also ships with the distribution (see doc > > directory). > >> >>>Other areas where the doc could be better: >>>-> A servlet example for doing "disconnected updates", where objects >> >>are >> >> >>>fetched from the database and displayed in a browser in one request, >> >>and >> >> >>>submitted back to the server for update in the database on a different >>>request. Figuring out how to do this with the ODMG API initially was >>>frustrating for me. I eventually ditched the ODMG API and started >> >>using the >> >> >>>PersistenceBroker API and I like it much better ... particularly the >>>Querying classes. The packaged servlet example was too simple for >> >>what I >> >> >>>needed to do. >>> >> >> >>We have a full fledged Struts/OJB demo application in our > > contributions > >>package. I think it's worth a look. >> >> >> >>>-> Threading. More discussion about how to properly use the API(s) in >> >>a >> >> >>>multi-threaded environment. It took a lot of reading on the mailing >> >>lists >> >> >>>to figure out how to handle this issue, which I still have to >> >>implement if >> >> >>>we end up selecting OJB. >>> >> >> >>We have some threading testcases, but I think they are not very useful > > >>as code templates. >> >>All users that have interesting solutions that could be helpful for >>others are requested contrbute theirs code along with a short >>explanation. We will add such best practises examples to our >>docuemntation (or if a certain size is exceeded to the contribution >>package). >> >> >> >>>-> The more query examples the better. Hibernate does pretty good >> >>here. >> >> >>>They have many examples on using the querying language (which, >> >>incidentally, >> >> >>>thus far I think is harder to use than the OJB PB Querying classes). >> >> >>There is the query.html documentation. There are also tons of query >>samples in the testcases. >>As always: user examples are most welcome ! >> >> >> >> >>>-> A matrix (or Pro/Con list) to compare each API within OJB >>>(PeristenceBroker, ODMG, JDO) would be helpful. >> >> >>Good idea. I'll try to setup such a list. >> >> >> >>>I first picked the ODMG API >>>when I started because I thought it would be good to stick with a >> >>standard. >> >> >>>After converting to the PB API, though, I think it's much easier to >> >>use and >> >> >>>my code is much simpler. >> >> >>PB gives you more control, it's much faster and you have the nice PB >>queries. >>On the other hand you have to do a lot of things explicitly that are >>hidden by ODMG. (e.g. determination if an INSERT or an UPDATE is >>necessary for a certain Object) >> >> >> >>>If I had known that the PB API had these >>>qualities, I don't think I would have spent anytime looking at the >> >>ODMG API. >> >>I get your point. I once placed a comparison of ODMG and PB into the >>faq.html. I will extend this section with your pro/cons list. >> >> >> >>>-> I like the style of the Hibernate docs, presented in a user guide >> >>format, >> >> >>>easily navigable. >> >> >>I'll have a closer look at it. >> >> >> >>>3. Performance. The person that wrote the thread about performance, >> >>said >> >> >>>that they did some kind of performance test with both and that there >> >>was a >> >> >>>factor of nine difference between the two. A bold statement, and one >> >>that >> >> >>>deserves a gander I think. On the hibernate forum: >>>http://sourceforge.net/forum/message.php?msg_id=1645215 >>> >> >> >>I read the whole thread. There was only a claim, but no further proof > > or > >> anything. >>I won't spend my time commenting on such FUD. I want to see the test >>code and I want to see relevant information on the environment and I >>want to see exact figures. >> >> >> >>>4. All that being said, after trying a parallel test with Hibernate, >> >>I'm >> >> >>>not sold on their API as of yet. I am experiencing some problems with >>>many-to-one mappings on composite keys that I didn't experience with >> >>OJB. >> >> >>>Also, with the little bit of coding I've done, I think I like the OJB >>>querying classes better. The less writing of SQL/OQL-like code, the >> >>better >> >> >>>I think. >> >> >>I agree. I also don't like ODMG OQL. Thus I implemented the ODMG query > > >>layer in a way that allows to use the much handier PB QUeries also >>inside OJB ODMG apps. (See the faq.html for more details). >> >>We are running this "mixed" mode in several mission critical >>applications for our customers. >> >> >> >>>Also the less code I have to write to build query strings the >>>better. >> >> >>assembling query strings (be it SQL or OQL) hurts my object oriented >>aesthetics too. >> >> >> >>>For instance writing a dynamic query in Hibernate that corresponds >>>to the following SQL was cumbersome: >>> >>>SELECT * from customer where customer_id IN ( 1, 2, 3, 4, 5) >>> >>>Whereas the same query in OJB is simple. >>> >>>Glad to hear that you are operating under the same environment that we >> >>are >> >> >>>targetting! I may have DB2 OS/390 questions for you in the future >> >>(but >> >> >>>hopefully everything will just *work* when I move from HSQL to DB2). >>> >> >> >>We had several problems with context switches (from the webserver >>account to the technical application account used inside DB2) of the > > DB2 > >>driver. But AFAIK these issues are fixed in Version 7.x. >> >>To avoid problems you should start as soon as possible to test your >>stuff on OS/390. There are a lot of lessons to learn (not at all OJB >>related !). >> >>If you have any problems don't hesitate to ask. >>cheers, >>Thomas >> >> >> >>>Thanks, >>>Jason >>> >>> >>>----- Original Message ----- >>>From: "Thomas Mahler" <[EMAIL PROTECTED]> >>>To: "OJB Users List" <[EMAIL PROTECTED]> >>>Sent: Friday, October 04, 2002 3:34 PM >>>Subject: Re: PersistenceBroker or ODMG? >>> >>> >>> >>> >>> >>>>Hi again, >>>> >>>>Jason Mihalick wrote: >>>> >>>> >>>> >>>>>Jeff, >>>>> >>>>>Wow. You are targetting the same platforms as us! As of right now >>>> >>>(which >>> >>> >>> >>>>>could change very soon depending on support for Struts), we are also >>>>>targetting WAS 3.5. >>>> >>>>After some trouble wrt. to placing struts-config.xml into the correct >>>>classloader path we are running struts apps on WS 3.5 / OS390 without >>>>problems. >>>> >>>> >>>> >>>> >>>>>You bring up an interesting point. We have not considered locking >>>>>strategies. I think that optimistic locking is what we need, but I >>>> >>was >> >> >>>not >>> >>> >>> >>>>>aware that OJB does not support this. >>>>> >>>> >>>>Once and for all: *OJB does support optimistic locking*. There are >>>>several testcases covering this feature. >>>> >>>> >>>> >>>> >>>>>Also, since I have sent my prior messages, we have discovered >>>> >>Hibernate >> >> >>>and >>> >>> >>> >>>>>I will be evaluating it today. Hibernate looks *very* promising. >>>> >>Some >> >> >>>of >>> >>> >>> >>>>>the things I like about Hibernate vs. OJB: >>>>> >>>>>-> No need for additional system tables to support the API >>>> >>>>You can run OJB without any internal tables! >>>>1. If you want to use OJB sequence numbers you only have to implement >>> >>a >> >> >>>>SequenceManager that does not rely on a table (If users think this is >>> >>an >> >> >>>>important feature we can add such a simplified SequenceManager to the >>>>main distribution). >>>>2. all other internal tables are only needed if you are using special >>>>ODMG features like persistent collections. These collections are >>>>specified by ODMG. So you you cannot blame OJB for those tables. >>>> >>>> >>>> >>>> >>>> >>>>>-> Threads I've read say that Hibernate is thinner, giving better >>>>>performance >>>> >>>>OJB is providing a performance testsuite that allows to compare >>> > native > >>>>JDBC performance against PersistenceBroker performance. >>>> >>>>I'd love to see this test reimplemented for other tools like >>> > Hibernate > >>>>to have a direct comparison. >>>> >>>>Everything else is mere speculation. >>>> >>>> >>>> >>>> >>>> >>>>>-> Documentation is *excellent* >>>>> >>>> >>>>Hibernate docs are in good shape. It's well structured and written by >>>>native english speakers. >>>>I'm german and my english is not perfect... >>>> >>>>But apart from style and grammar: what is missing in OJB >>> >>documentation? >> >> >>>>How can we improve the overall structure of the documentation? >>>> >>>>cheers, >>>>Thomas >>>> >>>> >>>> >>>> >>>>>-- >>>>>Jason >>>>> >>>>>----- Original Message ----- >>>>>From: "Boring, Jeff W, ALBAS" <[EMAIL PROTECTED]> >>>>>To: "OJB Users List" <[EMAIL PROTECTED]> >>>>>Sent: Thursday, October 03, 2002 10:43 AM >>>>>Subject: RE: PersistenceBroker or ODMG? >>>>> >>>>> >>>>>Jason/Suresh: >>>>> >>>>>I read with interest some of the messages in your tread. We are also >>>>>considering PB, ODMG and Hibernate. Another similarity we have is >>>> > DB2 > >>>7.1 on >>> >>> >>> >>>>>OS/390 and we are also using WebSphere v3.5 on the 390. >>>>> >>>>>For us, the lack optimistic locking support is driving us from >>>> >>OJB.ODMG. >> >> >>>>>Have you considered this issue? What kind of locking strategy is >>>> > your > >>>app >>> >>> >>> >>>>>using? >>>>> >>>>>Jeff Boring >>>>>Custom & Web Services Development >>>>>AT&T Labs >>>>>[EMAIL PROTECTED] >>>>> >>>>>-----Original Message----- >>>>>From: Jason Mihalick [mailto:[EMAIL PROTECTED]] >>>>>Sent: Thursday, October 03, 2002 6:09 AM >>>>>To: [EMAIL PROTECTED] >>>>>Subject: Re: PersistenceBroker or ODMG? >>>>> >>>>> >>>>>This was a response that I just sent directly to another person on >>>> >>the >> >> >>>list. >>> >>> >>> >>>>>Hopefully it helps... >>>>> >>>>> >>>>>======== >>>>>Suresh, >>>>> >>>>>No, I have not changed to Castor. Half of my problems were fixed by >>>>>refactoring my code to use the PersistenceBroker API instead of the >>>> >>ODMG >> >> >>>>>API. I was having problems with aborting transactions with the ODMG >>>> >>>API. >>> >>> >>> >>>>>That aside, I think I like the PersistenceBroker API much better >>>> >>anyway. >> >> >>>>>The little bit of persistence code that I had written went down from >>>> >>>about >>> >>> >>> >>>>>900 lines to 650 lines. From what I've seen so far, it seems like a >>>> >>>fairly >>> >>> >>> >>>>>elegant API .... AND .... it appears to allow access to a JDBC >>>> >>>Connection >>> >>> >>> >>>>>which is good for us since we will probably be making calls to >>>> > Stored > >>>>>Procedures, which isn't possible under the ODMG API. >>>>> >>>>>The remaining problems that I need to resolve are the threading >>>> >>issues. >> >> >>>I >>> >>> >>> >>>>>have read a couple of threads on the mailing list about how to >>>> > remedy > >>>this. >>> >>> >>> >>>>>One person suggested that all I had to do was create a new >>>> >>>PersistenceBroker >>> >>> >>> >>>>>for each query, since the PersistenceBrokers are pooled. I have not >>>>>verified this yet, but it sounds promising. Right now, I just have >>>> >>>Tomcat >>> >>> >>> >>>>>running with a single HttpProcessor thread and things are working. >>>> >>I'll >> >> >>>>>attempt to remedy the threading issue on our next deliverable. I >>>> >>plan >> >> >>>to >>> >>> >>> >>>>>continue using OJB assuming (1) that I don't have a lot of issues >>>> >>when I >> >> >>>>>change our backing database from HSQL to DB2 v7.1 for OS/390, (2) I >>>> >>can >> >> >>>get >>> >>> >>> >>>>>support from our other team members that OJB is the way-to-go, and >>>> >>(3) I >> >> >>>can >>> >>> >>> >>>>>resolve the threading issue. >>>>> >>>>>As far as performance goes, it seems really good to me so far, but >>>> > at > >>>this >>> >>> >>> >>>>>point we have only been dealing with small tables, few rows in the >>>> >>>tables, >>> >>> >>> >>>>>and business logic that supports maintainence of the rows in the >>>> >>tables. >> >> >>>We >>> >>> >>> >>>>>haven't started doing real query-intensive business logic yet. >>>>> >>>>>After I switched to the PersistenceBroker API, I must admit that my >>>> >>>attitude >>> >>> >>> >>>>>about OJB changed significantly. I've stopped fighting it, and have >>>> >>>really >>> >>> >>> >>>>>been quite productive with it. >>>>> >>>>>-- >>>>>Jason >>>>> >>>>>----- Original Message ----- >>>>>From: "Avadhanula, Suresh" <[EMAIL PROTECTED]> >>>>>To: "Avadhanula, Suresh" <[EMAIL PROTECTED]>; "Jason Mihalick" >>>>><[EMAIL PROTECTED]> >>>>>Sent: Wednesday, October 02, 2002 2:51 PM >>>>>Subject: RE: Initializing OJB >>>>> >>>>> >>>>>Hi Jason >>>>>Have you changed to Castor? Were the threading issues in OJB fixed >>>> > in > >>>>>0.9.6? You reported that QueryByExample was missing in the latest >>>>>release. Is this fixed? >>>>>What is the performance you see with OJB? >>>>> >>>>>Thanks >>>>>Suresh >>>>> >>>>>-----Original Message----- >>>>>From: Avadhanula, Suresh >>>>>Sent: Tuesday, October 01, 2002 3:46 AM >>>>>To: 'Jason Mihalick' >>>>>Subject: RE: Initializing OJB >>>>> >>>>> >>>>>I just went thro your posts... I have just started using OJB so yet >>>> >>to >> >> >>>>>encounter the threading issues. >>>>> >>>>>I am trying out OJB, hence havent exactly made up my mind to ditch >>>>>Castor. Although I favour OJB so far. Having said that, here are >>>> > thee > >>>>>reasons.. >>>>> >>>>>Cons: >>>>>1) Castor uses only JDO which is not the standard JDO proposed by >>>> >>Java. >> >> >>>>>2) I cannot swith between standards like ODMG, JDO and reflection >>>>>(Persistence API). >>>>>3) The code is not very clean and documented, hence if I want to >>>> >>change >> >> >>>>>anything or figure out anything its a pain. I have had huge problems >>>>>trying >>>>> to store Maps (Hastables, HashMaps) using Castor-XML. I ended up >>>>>using Apache SOAP's serializer in castor FieldHandler which defeats >>>> >>the >> >> >>>>>whole purpose of using castor. >>>>>4) There are no adequeate tools available except for SourceGenertor >>>>>which is used only for Castor-XML and not JDO. >>>>> >>>>>Pros: >>>>>1) Castor has been present for long time. >>>>>2) Usage perspective, its pretty decent. >>>>> >>>>>Coming to OJB: >>>>>You probably have more experience with OJB than I do. >>>>>I am looking at OJB for the following reasons.. Standards, hence if >>>> > I > >>>>>choose to go the JDO route or ODMG route.. I dont have to change a >>>> >>lot. >> >> >>>>>The main reason I like OJB is PersistenceBrokerAPI (which is not a >>>>>standard). The reason for that is, I need to have the SQL generated >>>>>automatically. >>>>>I like the >>>>>Query = new QueryByExample(queryObject); // Where queryObject is a >>>>>sample object with only some feilds filled in.. >>>>> >>>>>I was gonna end up writing something similar.. well not OJB gives it >>>> >>to >> >> >>>>>me. >>>>> >>>>>As for as the threading issues.. I need to see if I run into the >>>>>problems. I doubt that I would as I can request a new >>>> >>PersistenceBroker >> >> >>>>>everytime as its all pooled >>>>>internally. But I need to check. >>>>> >>>>>Hope that helps. >>>>>-Suresh >>>>> >>>>> >>>>> >>>>>-----Original Message----- >>>>>From: Jason Mihalick [mailto:[EMAIL PROTECTED]] >>>>>Sent: Monday, September 30, 2002 6:33 PM >>>>>To: Avadhanula, Suresh >>>>>Subject: Re: Initializing OJB >>>>> >>>>> >>>>>Would you mind me asking why you are shifting from Castor to OJB? I >>>> >>was >> >> >>>>>just considering doing the opposite. See my last two posts as to >>>> >>why: >> >> >>>>>http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@jakar >>>> > t > >>a.a >> >> >>>>>pach >>>>>e.org&msgNo=2809 >>>>>http://archives.apache.org/eyebrowse/ReadMsg?listName=ojb-user@jakar >>>> > t > >>a.a >> >> >>>>>pach >>>>>e.org&msgNo=2831 >>>>> >>>>>Thanks, >>>>>Jason >>>>> >>>>> >>>>>----- Original Message ----- >>>>>From: "Hemant Gokhale" <[EMAIL PROTECTED]> >>>>>To: <[EMAIL PROTECTED]> >>>>>Sent: Wednesday, October 02, 2002 8:26 PM >>>>>Subject: PersistenceBroker or ODMG? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>I am new to OJB and looking for some advice on choosing between the >>>>>>PersistenceBroker and the ODMG API. Thanks in advance for your >>>>> > help. > >>>>>>We are developing a set of simple servlet based applications. And I >>>>>>would like to use OJB for persistence. Our scalability requirements >>>>> >>are >> >> >>>>>>modest. I am looking at less than 10 simultaneous requests. I would >>>>> >>like >> >> >>>>>to >>>>> >>>>> >>>>> >>>>> >>>>>>keep the code as simple and small as possible. I plan to use OJB in >>>>> >>a >> >> >>>>>single >>>>> >>>>> >>>>> >>>>> >>>>>>VM mode (not client server). >>>>>>I have looked at both the options of using the persistence broker >>>>>>directly and using the ODMG API. My initial inclination was to use >>>>> >>the >> >> >>>>>ODMG >>>>> >>>>> >>>>> >>>>> >>>>>>API. But on closer inspection I found using the PersistenceBroker >>>>> >>>directly >>> >>> >>> >>>>>>would be simpler and potentially faster. The added advantage of >>>>> >>using >> >> >>>>>>PersistenceBroker is that I can use auto-delete and auto-update >>>>> >>features >> >> >>>>>to >>>>> >>>>> >>>>> >>>>> >>>>>>make my code even smaller. >>>>>>The only problem with this approach is the possibility of two >>>>>>threads modifying the same object in the object cache. I came up >>>>> >>with >> >> >>>the >>> >>> >>> >>>>>>following strategy to deal with this problem. >>>>>>Can one of the more experienced people please tell me if this >>>>>>approach with work? Or am I on a wrong track? >>>>>> >>>>>>* Create a pool of persistence brokers. The application is expected >>>>> >>to >> >> >>>>>>receive only a few simultaneous requests. So the pool is not >>>>> >>expected to >> >> >>>>>>grow very large. >>>>>>* Inside actionObject.perform() method, before any database >>>>>>interaction >>>>>>* get a broker from the pool >>>>>>* start a transaction tx >>>>>>* Do all your db access using the tx >>>>>>* At the end of all database interaction (still inside >>>>>>actionObject.perform() method) >>>>>>* either commit or abort the tx >>>>>>* release the broker to the pool. >>>>>> >>>>>> >>>>>>Thanks. >>>>>> >>>>>>-Hemant >>>>>> >>>>>>-- >>>>>>To unsubscribe, e-mail: >>>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>>>For additional commands, e-mail: >>>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>>-- >>>>>To unsubscribe, e-mail: >>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>>For additional commands, e-mail: >>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>>-- >>>>>To unsubscribe, e-mail: >>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>>For additional commands, e-mail: >>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>>-- >>>>>To unsubscribe, e-mail: >>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>>For additional commands, e-mail: >>>> >>><mailto:[EMAIL PROTECTED]> >>> >>>>> >>>>-- >>>>To unsubscribe, e-mail: >>> >><mailto:[EMAIL PROTECTED]> >> >>>>For additional commands, e-mail: >>> >><mailto:[EMAIL PROTECTED]> >> >>>-- >>>To unsubscribe, e-mail: >> >><mailto:[EMAIL PROTECTED]> >> >>>For additional commands, e-mail: >> >><mailto:[EMAIL PROTECTED]> >> >>> >>> >> >> >>-- >>To unsubscribe, e-mail: >><mailto:[EMAIL PROTECTED]> >>For additional commands, e-mail: >><mailto:[EMAIL PROTECTED]> >> >> >>-- >>To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > >> >> >> > > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
