Setting eager release to false solves the issue ro me.
fortunately I am going to production on on tomcat 4 therefore the eager
release setting does not need to be set to true.
I had set it to true when trying out jboss
My set up is
Tomcat 4.x
mySQL 4
OJB 1.0 rc3
cheers to everyone speaking up about this one!
Jin
----- Original Message -----
From: "Thomas Mahler" <[EMAIL PROTECTED]>
To: "Gary Richards" <[EMAIL PROTECTED]>; "OJB Users List"
<[EMAIL PROTECTED]>
Sent: Monday, June 02, 2003 8:15 PM
Subject: Re: Limited collection returned
> Hi again,
>
> Gary Richards wrote:
> > Hi,
> >
> > It's almost certain (at least for me with JBoss) the eager-release. I
> > turned it off and everything i expected came back through the query.
> >
>
> That's what I expected. I had a closer look at the code.
> OJB uses a class StatementManager to handle jdbc statement resources.
> the method StatementManager.closeResources(Statement stmt, ResultSet rs)
> is meant to close a statement after use.
>
> it contains the following lines:
> /*
> *********************************************
> special stuff for OJB within JBoss
> ********************************************
> */
> if (m_eagerRelease)
> {
> m_conMan.releaseConnection();
> }
>
> clsoing the underlying connection will avoid the JBOSS "Successfully
> closed a connection for you" messages.
> But it is problematic because a PersistenceBroker uses only one
> connection. once the connection is released other operations executed by
> the same broker instance will fail!
>
> The only safe point to release a connection is in the broker commit() or
> abort() methods! This looks like a design issue.
> But I am not sure as I did not add this feature. I hope Armin can spread
> some more light on this...
>
> For the time being I think the only safe option is to set eager-release
> to false.
>
> We than have to have a closer look at the ODMG insert problem you have.
> Do you see any OJB related exceptions in the stacktrace? Or only those
> org.jboss.resource.connectionmanager.* exceptions? (They look like
> warnings to me and should not do any harm?!)
>
> cheers,
> Thomas
>
>
> > Did get a few stack traces of the sort [CachedConnectionManager]
> > Successfully closed a connection for you. Please close them
> > yourself: [EMAIL PROTECTED]
> >
> > at
> >
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(Cached
ConnectionManager.java:376)
> > at
> >
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObj
ect(CachedConnectionManager.java:199)
> > at
> >
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(Cach
edConnectionInterceptor.java:190)
> > at
> >
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess
ionInstanceInterceptor.java:271)
> > etc...
> >
> >
> > I had eager-release on as thats's what it said to do in the
> > deployment docs for JBoss 3.0 and greater. Unfortuanately inserts
> > don't seem to work for ODMG when setting eager-release to false. I
> > get a first stack trace,
> >
> > 18:08:22,070 INFO [CachedConnectionManager] Successfully closed a
> > connection for you. Please close them yourself:
> > [EMAIL PROTECTED]
> > java.lang.Exception: Stack Trace at
> >
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(Cached
ConnectionManager.java:376)
> > at
> >
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObj
ect(CachedConnectionManager.java:199)
> > at
> >
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(Cach
edConnectionInterceptor.java:190)
> > at
> >
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess
ionInstanceInterceptor.java:271)
> >
> >
> > followed by a few pages of
> >
> > 18:08:22,070 INFO [CachedConnectionManager] Successfully closed a
> > connection for you. Please close them yourself:
> > [EMAIL PROTECTED]
> > java.lang.Exception: Stack Trace at
> >
org.jboss.resource.connectionmanager.CachedConnectionManager.closeAll(Cached
ConnectionManager.java:376)
> > at
> >
org.jboss.resource.connectionmanager.CachedConnectionManager.popMetaAwareObj
ect(CachedConnectionManager.java:199)
> > at
> >
org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(Cach
edConnectionInterceptor.java:190)
> > at
> >
org.jboss.ejb.plugins.StatefulSessionInstanceInterceptor.invoke(StatefulSess
ionInstanceInterceptor.java:271)
> > etc...
> >
> > which is probably why we need eager-release for JBoss. Presumably the
> > eager-release gives OJB a hint to cleanup its connections before
> > JBoss comes to repossess them.
> >
> > regards
> >
> > Gary
> >
> >
> > -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED]
> > Sent: 02 June 2003 17:44 To: OJB Users List Subject: Re: Limited
> > collection returned
> >
> >
> > So both of you use the eager-release="true" feature. Have you tried
> > to disable it?
> >
> > Maybe Armin knows a bit more about this feature ?
> >
> > cheers, Thomas
> >
> > Ken Dempster wrote:
> >
> >> My setup is as follows: Jboss 3.2.1 OBJ 1.0 RC3 OJB.properties set
> >> to PersistenceBrokerImpl, PersistenceBrokerFactoryDefaultImpl, and
> >> ConnectionFactoryManagedImpl, ObjectCachePerBrokerImpl. DB2
> >> database Server AS400 running both Jboss and DB2 I generate my own
> >> JdbcConnectionDescriptor with the following settings:
> >> JdbcConnectionDescriptor descriptor = new
> >> JdbcConnectionDescriptor(); descriptor.setBatchMode(false);
> >> descriptor.setDatasourceName("java:DB2DS");
> >> descriptor.setDbAlias("serverName"); descriptor.setDbms("Db2");
> >> descriptor.setDefaultConnection(true);
> >> descriptor.setEagerRelease(true);
> >> descriptor.setIgnoreAutoCommitExceptions(false);
> >> descriptor.setJcdAlias("java:DB2DS");
> >> descriptor.setJdbcLevel("2.0"); descriptor.setPassWord("password");
> >> descriptor.setProtocol("jdbc"); descriptor.setSubProtocol("db2");
> >> descriptor.setUseAutoCommit(0);
> >> descriptor.setUserName("user_name"); SequenceDescriptor
> >> sequenceDescriptor = new
> >>
SequenceDescriptor("org.apache.ojb.broker.util.sequence.SequenceManagerN
> >> extValImpl");
> >>
> >> - Ken
> >>
> >>
> >>
> >>
> >>
> >>
> >> Ken Dempster Programmer Analyst Vision Solutions, Inc.
> >>
> >> 17911 Von Karman Ave, 5th Floor Irvine, CA 92614 UNITED STATES
> >>
> >> Tel: +1 (949) 253-6500 Fax: +1 (949) 253-6501 Email:
> >> [EMAIL PROTECTED] <http://www.visionsolutions.com/>
> >> Disclaimer - 6/2/2003 The contents of this e-mail (and any
> >> attachments) are confidential, may be privileged, and may contain
> >> copyright material of Vision Solutions, Inc. or third parties. You
> >> may only reproduce or distribute the material if you are expressly
> >> authorized by Vision Solutions to do so. If you are not the
> >> intended recipient, any use, disclosure or copying of this e-mail
> >> (and any attachments) is unauthorized. If you have received this
> >> e-mail in error, please immediately delete it and any copies of it
> >> from your system and notify us via e-mail at
> >> [EMAIL PROTECTED] -----Original Message----- From:
> >> McCaffrey, John G. [mailto:[EMAIL PROTECTED] Sent: Monday,
> >> June 02, 2003 8:02 AM To: 'OJB Users List' Subject: RE: Limited
> >> collection returned
> >>
> >>
> >> Thanks for your investigation Gary. This is exactly what I was
> >> suspecting (RSIterator not iterating), now I guess the thing is to
> >> figure out how the result set got closed. I am not sure why there
> >> seem to be only a few people having this problem, it seems like
> >> such basic functionality that there would be more of an uproar. It
> >> makes me wonder what the afflicted have in common, and for those
> >> people that can get a collection of dependent objects, how is their
> >> setup different (assuming that there are people that are not having
> >> this problem)
> >>
> >> my setup I have the basic OJB.props settings default
> >> PersistenceBrokerImpl, PersistenceBrokerFactoryDefaultImpl,
> >> ConnectionManagerImpl, and I am using ConnectionFactoryDBCPImpl
> >> (though I have tried the others and still have the problem).
> >>
> >> Windows 2000, db-ojb-1.0.rc3.jar, commons-dbcp.jar I am using WSAD
> >> (with datasource) and DB2, and I am using the PB API.
> >>
> >>
> >> ###### Gary, Dan, Jin, Ken, etc what is your basic setup?
> >>
> >> Is there anybody with this same setup that is able to get a
> >> collection of dependent objects? (help me figure out what i have
> >> that is different) ###### I feel like a solution is right around
> >> the corner. (and its a good thing, because I am supposed to go to
> >> production by the end of the week!)
> >>
> >> Thanks to Gary and everyone that is looking into this. -john
> >>
> >> -----Original Message----- From: Gary Richards
> >> [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2003 9:05 AM To:
> >> OJB Users List Subject: RE: Limited collection returned
> >>
> >>
> >>
> >> Hi everyone,
> >>
> >> Thought I'd offer my current observations on this as I work with
> >> Dan and am running off the same codebase (JBoss 3.2.x, MySql, ODMG
> >> etc....) and therefore trying to crack the same problem.
> >>
> >> I've been using the eclipse debugger to step through the action of
> >> invoking a query. I have spent most of the recent time observing
> >> private ManageableCollection getCollectionByQuery(Class
> >> collectionClass, Class itemClass, Query query) of the
> >> PersistanceBrokerImpl class (line 1293), inparticular the actions
> >> of the while loop on line 1335 which reads as,
> >>
> >> while (((endAt == Query.NO_END_AT_INDEX) || (retrievedCount <
> >> numberOfObjectsToFetch)) && iter.hasNext())
> >>
> >> I have witnessed the hasNext() call of this condition to return
> >> false during the second cycle of the loop, even though I now there
> >> to be 13 rows in the database table and 13 elements behind the
> >> Iterator. I have determined this (for those who know eclipse) by
> >> editing the detail formatter of the RSIterator class to read
> >> "this.size()" which shows 13 when I highlight it.
> >>
> >> This leads me onto RSIterator.hasNext() (line 216) which I have
> >> moved onto observe as a result. I noticed that on the second cycle
> >> of the iterator, the call from within hasNext() will issue
> >>
> >> hasNext = m_rsAndStmt.m_rs.next(); (line 223)
> >>
> >> This throws an expection which is caught by the same method so that
> >> false is returned.
> >>
> >> catch (Exception ex) { hasNext = false; }
> >>
> >> I have noticed that the message given by this exception ex (which
> >> is not logged, only gets caught) is "Operation not allowed after
> >> ResultSet closed". This certainly suggests that something has
> >> closed the ResultSet before the iterator has been fininshed with
> >> (exactly what it says in the message ;) ).
> >>
> >> This almost always seems to happen after dependant objects have
> >> been retieved as when we set auto-retrieve = "false" in
> >> repository_user.xml for the appropriate property we get all rows of
> >> the single table we query on but no dependant objects, however when
> >> we set auto-retrieve = "true" we get only the first row of the
> >> single table and all its dependant objects.
> >>
> >> Is this possibly linked to the eager-release feature which needs to
> >> be enabled for operation on JBoss, or a side effect of bug OJB172?
> >>
> >> Any other thoughts?
> >>
> >> regards
> >>
> >> Gary
> >>
> >>
> >> -----Original Message----- From: Dan Hanley Sent: Mon 02/06/2003
> >> 14:38 To: OJB Users List Cc: Subject: RE: Limited collection
> >> returned
> >>
> >> Jin Are you also running in a managed environment (e.g. jBoss)? I
> >> suspect the bug you're referring to is: Type : Defect Issue
> >> Id : OJB172 Reported by: Rob Kischuk rkischuk - (rkischuk <at>
> >> gttx.org) Details: Platform: PC Operating system: windows 2000
> >> Summary: Loading composite object leads to truncated collection
> >> Description: Repeated calls to retrieve a collection of objects
> >> that each contain another object are retrieving truncated results,
> >> which are incrementally built to their proper length using repeated
> >> requests. Status: New Priority: Undecided Severity: Major
> >> Functional area: Setup ... which sounds like it could be the
> >> culprit. A colleague of mine is trying to trace through with the
> >> eclipse debugger to see if we can cast any light on this. You are
> >> not alone, its holding a lot of people up... Dan -----Original
> >> Message----- From: Jin Bal [mailto:[EMAIL PROTECTED] Sent: Fri
> >> 30/05/2003 22:07 To: OJB Users List Cc: Subject: Re: Limited
> >> collection returned I'm also having this problem - thank god
> >> someone else's said so ! it's been driving me mad ;-) i've been
> >> using ojb since 0.9.5 and have only noticed it recently. (sorry
> >> can't be more precise than that) here's the offending class
> >> descriptor <class-descriptor
> >> class="com.buyacar.businessobjects.Vehicle" table="vehicle">
> >> ....blah blah properties etc <!-- IMAGES -->
> >> <collection-descriptor name="images" auto-retrieve="true"
> >> element-class-ref="com.buyacar.businessobjects.VehicleImage">
> >> <inverse-foreignkey field-id-ref="1"/> </collection-descriptor>
> >> </class-descriptor> <class-descriptor
> >> class="com.buyacar.businessobjects.BACVehicleDetails"
> >> table="bac_details"> <reference-descriptor name="vehicle"
> >> class-ref="com.buyacar.businessobjects.Vehicle"
> >> auto-retrieve="true"> <foreignkey field-id-ref="2"/>
> >> </reference-descriptor> </class-descriptor> whenever I load a
> >> BACVehicleDetails (and therefore a Vehicle) I only ever get one
> >> image in the collection. more over I have a search engine that
> >> only returns 1 result the first time then 2 on the second submit
> >> then 3 ......etc :-( heres the search engine code
> >> PersistenceBroker broker = null; try { broker = getBroker();
> >> Criteria criteria = new Criteria(); // check if theyve specified a
> >> price bracket if(searchParams.getMaxPrice() !=null &&
> >> searchParams.getMinPrice()!=null) {
> >>
criteria.addBetween("price",searchParams.getMinPrice(),searchParams.getM
> >> axPr ice()); } else if(searchParams.getMaxPrice()!=null &&
> >> searchParams.getMinPrice()==null) {
> >> criteria.addLessOrEqualThan("price",searchParams.getMaxPrice()); }
> >> else if(searchParams.getMaxPrice()==null &&
> >> searchParams.getMinPrice()!=null) {
> >> criteria.addGreaterOrEqualThan("price",searchParams.getMinPrice());
> >> } if(searchParams.getManufacturer() !=null &&
> >> searchParams.getModel()==null) {
> >>
criteria.addEqualTo("vehicle.model.manufacturerId",searchParams.getManuf
> >> actu rer()); } if(searchParams.getModel() !=null) {
> >> criteria.addEqualTo("vehicle.modelId",searchParams.getModel()); }
> >> if(searchParams.getBodyStyle() != null) {
> >>
criteria.addEqualTo("vehicle.derivative.bodyStyleId",searchParams.getBod
> >> ySty le()); } if(searchParams.getFuelType() != null) {
> >>
criteria.addEqualTo("vehicle.derivative.fuelId",searchParams.getFuelType
> >> ()); } if(searchParams.getOrderBy() !=null) {
> >> criteria.addOrderByAscending(searchParams.getOrderBy()); }
> >> if(searchParams.getChannel()!=null &&
> >> !searchParams.getChannel().equals("")) {
> >> criteria.addEqualTo("channel",searchParams.getChannel()); }
> >> criteria.addEqualTo("status",searchParams.getStatus());
> >> criteria.addEqualTo("visibility",searchParams.getVisibility());
> >> criteria.addGreaterOrEqualThan("displayTo",new java.util.Date());
> >> criteria.addLessOrEqualThan("displayFrom",new java.util.Date());
> >> Query query = new
> >> QueryByCriteria(BACVehicleDetails.class,criteria,true); Collection
> >> c = broker.getCollectionByQuery(query); logger.debug("collection
> >> size: "+c.size()); Iterator results = c.iterator(); ArrayList list
> >> = new ArrayList(); while(results.hasNext()) { // perform cast now
> >> to check that we've got the correct object type BACVehicleDetails
> >> vDetails = (BACVehicleDetails) results.next(); list.add(vDetails);
> >> } return list; } finally { if (broker!=null) { broker.close(); } }
> >>
>
> >> sorry for the long code post it seems that when the cache is
> >> filled up it works ok help this is stopping me going live with the
> >> site :-( BTW I did a search on the dev list and noticed a bug
> >> opened on the 23rd MAy but i can't find it now cheers Jin -----
> >> Original Message ----- From: "McCaffrey, John G."
> >> <[EMAIL PROTECTED]> To: "'OJB Users List'"
> >> <[EMAIL PROTECTED]> Sent: Friday, May 30, 2003 5:52 PM
> >> Subject: RE: Limited collection returned > yes, I also noticed
> >> that, and I tried pre-fetching, but that didn't help me > either. >
> >> > so are you having the same problem then? You are only getting
> >> one row back, > instead of many? > > (my collection is filled
> >> properly with the right child elements, but I am > not getting all
> >> of the parents that match the query, and the query is select > all
> >> parents) > > can you see the SQL? I couldn't get P6Spy to work, so
> >> I don't know what the > sql looks like. > > thanks for speaking up,
> >> I wonder if anyone else has had/is having this > problem! > > -John
> >> > > -----Original Message----- > From: Dan Hanley
> >> [mailto:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 11:47 AM >
> >> To: OJB Users List > Subject: RE: Limited collection returned > > >
> >> John > Setting auto-retrieve = "false" works for me using JBoss &
> >> mySQL *except* > that then I don't get any dependant ojbects loaded
> >> :-( > > > -----Original Message----- > From: McCaffrey, John G.
> >> [mailto:[EMAIL PROTECTED] > Sent: 30 May 2003 17:45 > To:
> >> 'OJB Users List' > Subject: RE: Limited collection returned > > > I
> >> have been having the same problem. It seems like the initial query
> >> > actually gets all the rows, but the RSIterator only gives you one
> >> at a time. > In my situation if I have 4 rows that match the
> >> query, and I execute the > query once, I only get one row, each
> >> additional time I execute the query I > get one more row (all
> >> previous rows are also returned in the collection). > This is only
> >> happening for a referenced collection, all of my other queries >
> >> are working fine. I have no Idea what the deal is, I really hope
> >> that > someone can help you. > > -John > > -----Original
> >> Message----- > From: Ken Dempster
> >> [mailto:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003
> >> 11:38 AM > To: [EMAIL PROTECTED] > Subject: Limited collection
> >> returned > > > Most everything works except I only get one out of
> >> the know four row > objects from the table in my collection. I
> >> want to get all the row > objects in the table. My question is why
> >> am I only getting only one row > object? I am not sure what I am
> >> doing something wrong. > > Here is how I have things setup. I have
> >> set jboss 3.2 as suggested in > the deployment section of the
> >> documentation and have jboss configured it > with data source to
> >> connect to a DB2 database. I am requesting a > collection from a
> >> client to a SessionBean that delegates to a > PersistenceBroker
> >> instance. Basicly I am using the code in > PersistenceBrokerBean
> >> as a template for my EJB. I do generate my own >
> >> JdbcConnectionDescriptor and pass it to the ConnectionRepository
> >> instead > of using the repository.xml to define my
> >> JdbcConnectionDescriptor. > > My query looks as follows: > Query
> >> query = new QueryByCriteria(Runner.class, null); > > Collection
> >> list = > getPersistenceBrokerRemote().getCollectionByQuery(query);
> >> > > > My ClassDescriptor of the collection of objects I am trying
> >> to get is > defined in the repository_user.xml as follows : > >
> >> <class-descriptor class="test.ojb.Runner" table="KENLIB.RUNNER"> >
> >> > <field-descriptor name="m_id" column="ID" jdbc-type="INTEGER" >
> >> primarykey="true" autoincrement="true"/> > > <field-descriptor
> >> name="m_name" column="NAME" jdbc-type="VARCHAR"/> > >
> >> <collection-descriptor name="m_times"
> >> element-class-ref="test.ojb.Time"> > > <inverse-foreignkey
> >> field-ref="m_id"/> > > </collection-descriptor> > >
> >> </class-descriptor> > > <class-descriptor class="test.ojb.Race"
> >> table="KENLIB.RACE"> > > <field-descriptor name="m_id" column="ID"
> >> jdbc-type="INTEGER" > primarykey="true" autoincrement="true"/> > >
> >> <field-descriptor name="m_location" column="LOCATION" >
> >> jdbc-type="VARCHAR"/> > > <field-descriptor name="m_date"
> >> column="DATE" jdbc-type="DATE"/> > > </class-descriptor> > >
> >> <class-descriptor class="test.ojb.Time" table="KENLIB.RACE_TIME"> >
> >> > <field-descriptor name="m_id" column="ID" jdbc-type="INTEGER" >
> >> primarykey="true" autoincrement="true"/> > > <field-descriptor
> >> name="m_runner_id" column="RUNNER_ID" > jdbc-type="INTEGER"/> > >
> >> <field-descriptor name="m_race_id" column="RACE_ID" >
> >> jdbc-type="INTEGER"/> > > <field-descriptor name="m_time"
> >> column="TIME" jdbc-type="VARCHAR"/> > > <reference-descriptor
> >> name="m_race" class-ref="test.ojb.Race"> > > <foreignkey
> >> field-ref="m_race_id"/> > > </reference-descriptor> > >
> >> </class-descriptor> > > > > > Ken Dempster > Programmer Analyst >
> >> Vision Solutions, Inc. > > 17911 Von Karman Ave, 5th Floor >
> >> Irvine, CA 92614 > UNITED STATES > > Tel: +1 (949) 253-6500 > Fax:
> >> +1 (949) 253-6501 > Email: [EMAIL PROTECTED] >
> >> <http://www.visionsolutions.com/> > Disclaimer - 5/30/2003 > The
> >> contents of this e-mail (and any attachments) are confidential, may
> >> be > privileged, and may contain copyright material of Vision
> >> Solutions, Inc. or > third parties. You may only reproduce or
> >> distribute the material if you are > expressly authorized by Vision
> >> Solutions to do so. If you are not the > intended recipient, any
> >> use, disclosure or copying of this e-mail (and any > attachments)
> >> is unauthorized. If you have received this e-mail in error, >
> >> please immediately delete it and any copies of it from your system
> >> and > notify us via e-mail at [EMAIL PROTECTED] > > >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > For
> >> additional commands, e-mail: [EMAIL PROTECTED] > > >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > For
> >> additional commands, e-mail: [EMAIL PROTECTED] > >
> >> ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: [EMAIL PROTECTED] > For
> >> additional commands, e-mail: [EMAIL PROTECTED] > >
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> >> additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> >> additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [EMAIL PROTECTED] For
> >> additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED] For
> > additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
