I have to access 2 different collections sequentially. I necessarely make 2 different connection to the db?
Is there a method to move an accessor to another collection?

No, there is no method to move an accessor. An accessor is bound to one collection. However, what you should do is simply get yourself another accessor from the same TConnection object. So there is no need to open a second connection.

I’ll explain my problem. I have a classe Database
with the following constructor:
public Database(String databaseURI,
String collection) throws TConnectionException {
// Obtain the connection factory
TConnectionFactory connectionFactory =
// Obtain the connection to the database
connection = connectionFactory.newConnection( databaseURI );
// Obtain the concrete TXMLObjectAccessor using the JDOM object model
accessor = connection.newXMLObjectAccessor(
TAccessLocation.newInstance( collection ) ,
TJDOMObjectModel.getInstance() );

and so if i need to access another collection i have to instanciate another instance of the entire class (that include a new connection).
What to you think about?
Can the execution become slow?


I don’t have any figures to base this on, but I would expect that it takes longer to connect and create an Accessor than it does to create an Accessor from an existing Connection.
If this is true, then it would seem safe to assume that it will be slower to connect [unnecessarily] in order to change Collection.

As Christian pointed out, once a TConnection object exists it can be used to create an Accessor to any Collection in the database it is connected to…
Could you perhaps re-design your Database class a little so that it is possible to change the Collection/Accessor without calling the constructor?
I am thinking about adding a method something like this:

public void setCollection(String newCollection) {
   accessor = connection.newXMLObjectAccessor(TAccessLocation.newInstance( newCollection ),
                                              TJDOMObjectModel.getInstance() );

Of course, this might not be possible/appropriate, depending upon how the rest of the Database class is designed and implemented.