Hi Ralf,

Well I got this message...:

org.exolab.castor.jdo.PersistenceException: Nested error:
java.lang.IllegalArgumentException: A master object that involves in a long
transaction must be a TimeStampable!


I then implemented TimeStamable and got this message:
        org.exolab.castor.jdo.ObjectModifiedException: Timestamp mismatched!

John

-----Original Message-----
From: Ralf Joachim [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 01, 2006 07:06 PM
To: [email protected]
Subject: Re: [castor-user] How to implement castor?


Hi John,

the update method is designed for long transaction when object is
detached from the transaction. You can use it as follows:

        db.begin();
        student = (Student) db.find(100);
        db.commit();

        student.setFirstName("James");

        db.begin();
        db.update(student);
        db.commit();


This is very usefull if you load an object, display it to the user how
changes some of the properties and then you make these changes persistent.

Hope this helps
Ralf
Castor JDO, committer


John Greene schrieb:

>werner,
>
>I am doing an update as follows which works:
>
>        db.begin();
>        student = (Student) db.find(100);
>        student.setFirstName("James");
>        db.commit();
>
>But I dont understand why this does not work?
>        db.begin();
>        student = (Student) db.find(100);
>        student.setFirstName("James");
>        db.update(student);
>        db.commit();
>
>and gives a run time error message:
>
>       org.exolab.castor.jdo.DuplicateIdentityException: update object which is
>already in the transaction
>
>-----Original Message-----
>From: Werner Guttmann [mailto:[EMAIL PROTECTED]
>Sent: Sunday, January 29, 2006 06:31 AM
>To: [email protected]
>Subject: Re: [castor-user] How to implement castor?
>
>
>John,
>
>I think whilst your approach is very good and clean one, there's a
>couple of things to note.
>
>JDOManager.loadConfiguration() is a static method, and should be called
>once only to load a configuration with Castor JDO. A call to
>loadConfiguration() will instruct Castor JDO to take a JDO configuration
>file and load it, hence making all the information provided in that file
>available to Castor JDO for further use.
>
>JDOManager.createInstance() will create a JDOManager instance for a
>given database (as specified through the parameter passed to the call).
>There's no need to create this object instance more than once, as it is
>quite an expensive operation as well, and hence should not be performed
>on every method call of your DAO.
>
>In other words, consider moving the calls to
>JDOManager.loadConfiguration() and JDOManager.createInstance() to e.g.
>the constructor of your DAO (at the minimum).
>
>Once you've obtained your JDOManager instance through a call to
>JDOManager.createInstance(), use this JDOManager instance to create
>Database instances as you need them, use them, and discard them as well.
>
>Following your example below, let me explain what I actually mean. Let's
>add a load method to your DAO (one I am actually missing, as you won't
>for example be able to delete an object without loading it previously).
>
>public void load(Object identity) {
>   try {
>      Database db = _jdo.getDatabase();
>      db.begin();
>      db.load (SomeClass.class, identity);
>      db.commit();
>   }
>   catch (PersistenceException e) {
>      db.rollback();
>      // some other error handling, such as e.g. logging
>   }
>   finally {
>      db.close();
>   }
>}
>
>In the above load() method, the assumption is that your DAO has an
>instance variable _jdo of type JDOManager (which has been assigned the
>JDOManager instance as returned by JDOManager.createInstance()). We
>first call getDatabase() to obtain a Database instance, then deal with
>transaction demarcation and finally go about eventually loading the
>object in question, as specified by the identity object passed to the
>load method.
>
>Please have a close look at the exception handling, incl. the calls to
>Database.rollback() in the catch clause and Database.close() in the
>finally clause. These two calls are very important as they are required
>to guarantee data consistency (through properly committing/rolling back
>your units of work) and resource cleanup.
>
>I hope that gets you a bit further, and don't hesitate to ask any
>further questions related to what has just been said.
>
>Werner
>
>John Greene wrote:
>
>
>>Hi Werner,
>>
>>First thanks for the indications. I was googling the Internet since last
>>night and saw many different implementations of Castor that got me really
>>confused.
>>
>>Okay.... I have created the following DAO class:
>>
>>public class CastorDAO {
>>
>>    private static String _databaseName = "mydb";
>>    private static String _databaseConfiguration = "jdo-config.xml";
>>    protected static Database _db;
>>
>>    /** Creates a new instance of CastorDAO */
>>    public CastorDAO() {
>>
>>    }
>>
>>    public void loadDatabase() {
>>        try {
>>            JDOManager.loadConfiguration( _databaseConfiguration);
>>        } catch (MappingException e) {
>>            System.out.println(e);
>>        }
>>    }
>>
>>    public void open() {
>>        try {
>>            _db = JDOManager.createInstance(_databaseName).getDatabase();
>>        } catch (PersistenceException e) {
>>            System.out.println(e);
>>        } catch (MappingException e) {
>>            System.out.println(e);
>>        }
>>    }
>>
>>    public void create( Object object ) {
>>        try {
>>            _db.begin();
>>            _db.create( object );
>>            _db.commit();
>>        } catch (PersistenceException e) {
>>            System.out.println(e);
>>        }
>>    }
>>
>>    public void remove( Object object ) {
>>        try {
>>            _db.begin();
>>            _db.remove( object );
>>            _db.commit();
>>        } catch (PersistenceException e) {
>>            System.out.println(e);
>>        }
>>    }
>>
>>    public void update( Object object ) {
>>        try {
>>            _db.begin();
>>            _db.update( object );
>>            _db.commit();
>>        } catch (PersistenceException e) {
>>            System.out.println(e);
>>        }
>>    }
>>}
>>
>>To implement adding a NEW STUDENT I would do....
>>
>>      CastorDAO dao = new CastorDAO();
>>      dao.loadConfiguration;
>>      dao.create(student);
>>
>>
>>Question:
>>      dao.loadConfiguration; ----loads the configuration file,
>>
>>there is a method to close a database instance connection, however is
>>
>>
>there
>
>
>>a method to unload/close the database or test for presence; otherwise I'll
>>get a runtime Warning message indicating that the database has already
>>
>>
>been
>
>
>>loaded?
>>
>>Thanks
>>John.
>>
>>
>>-----Original Message-----
>>From: Werner Guttmann [mailto:[EMAIL PROTECTED]
>>Sent: Saturday, January 28, 2006 06:04 PM
>>To: [email protected]
>>Subject: Re: [castor-user] How to implement castor?
>>
>>
>>John,
>>
>>please see in line ....
>>
>>John Greene wrote:
>>
>>
>>
>>>I am unclear about how to go about implementing persistence using castor
>>>
>>>
>>in
>>
>>
>>
>>>my project. I have created my jdo-config.xml and mapping.xml files, made
a
>>>
>>>
>>t
>>
>>
>>
>>>est connection and everything works just fine.
>>>
>>>But now I want to implement for a project having many classes that need
>>>
>>>
>>pers
>>
>>
>>
>>>istence and I am a bit confused as how to go about it.
>>>
>>>Here is an example......:
>>>
>>>I have a Java object called "Student" that is mapped to an MySQL
database.
>>>
>>>public class Student {
>>>
>>>   private int _studentID;
>>>   private String _firstName;
>>>   private String _lastName;
>>>   private String _groups;
>>>
>>>
>>>   /** Creates a new instance of Student */
>>>   public Student() {
>>>       setStudentID(0);
>>>       setFirstName("");
>>>       setLastName("");
>>>       setGroups("");
>>>   }
>>>
>>>   public Student( int studentID, String firstName, String lastName,
>>>
>>>
>>String
>>
>>
>>
>>>group ) {
>>>       setStudentID(studentID);
>>>       setFirstName(firstName);
>>>       setLastName(lastName);
>>>       setGroups(group);
>>>   }
>>>
>>>   public int getStudentID() {
>>>       return _studentID;
>>>   }
>>>
>>>   public void setStudentID(int studentID) {
>>>       this._studentID = studentID;
>>>   }
>>>
>>>   public String getFirstName() {
>>>       return _firstName;
>>>   }
>>>
>>>   public void setFirstName(String firstName) {
>>>       this._firstName = firstName;
>>>   }
>>>
>>>   public String getLastName() {
>>>       return _lastName;
>>>   }
>>>
>>>   public void setLastName(String lastName) {
>>>       this._lastName = lastName;
>>>   }
>>>
>>>   public String getGroups() {
>>>       return _groups;
>>>   }
>>>
>>>   public void setGroups(String groups) {
>>>       this._groups = groups;
>>>   }
>>>}
>>>
>>>1st Problem:
>>>
>>>Should this class implement the Persistence class?  ...for example:
>>>
>>>      public class Student implements Persistence {
>>>
>>>
>>>
>>Not necessarily,
>>Not necessarily, unless you need the functionality the Persistence
>>interface offers, like the callback functions. If not, there's no need
>>to implement any interfaces to be able to persist your Student class
>>(and others) with Castor JDO.
>>
>>
>>
>>
>>>2nd Problem:
>>>I think that the create, update, remove student methods should be part of
>>>
>>>
>>th
>>
>>
>>
>>>e Student class.
>>>
>>>
>>In my view, that's not necessarily a good idea. Personally, I prefer to
>>see my entities (like e.g the Student class) as a POJO, a plain old Java
>>object that simply has a well-defined state at any time (through the
>>property values attached to a Student instance). Given this approach,
>>I'd rather prefer to have a DAO object that offers persistence-related
>>functionality for a particular entity, and hence provides methods for
>>the CRUD operations and more (if required).
>>
>>
>>
>>>Do I therefore need to include code to load the jdo-cong.xml
configuration
>>>
>>>
>>f
>>
>>
>>
>>>ile inside of Student?
>>>
>>>     JDOManager.loadConfiguration("jdo-config.xml");
>>>
>>>I tried this and got a Warning message for each new instance of Student,
>>>
>>>
>>ind
>>
>>
>>
>>>icating that the database has already been loaded.
>>>
>>>How can I test if the database has been loaded already?
>>>
>>>
>>>3rd Problem
>>>My project has numerous classes, each needing mapping to the MySQL
>>>
>>>
>>database.
>>
>>
>>
>>>What would be the best way to implement this?
>>>
>>>
>>Just define mappings for all your classes, carefully think about how to
>>relate those objects to each-other, and use your DAOs to load, update,
>>remove, etc your objects (well, object graphs, to be more precise) with
>>the help of Castor JDO.
>>
>>
>>
>>
>>>Thanks in advance
>>>
>>>
>>>
>>>-------------------------------------------------
>>>If you wish to unsubscribe from this list, please
>>>send an empty message to the following address:
>>>
>>>[EMAIL PROTECTED]
>>>-------------------------------------------------
>>>
>>>
>>>
>>>
>>
>>-------------------------------------------------
>>If you wish to unsubscribe from this list, please
>>send an empty message to the following address:
>>
>>[EMAIL PROTECTED]
>>-------------------------------------------------
>>
>>
>>
>>
>>-------------------------------------------------
>>If you wish to unsubscribe from this list, please
>>send an empty message to the following address:
>>
>>[EMAIL PROTECTED]
>>-------------------------------------------------
>>
>>
>>
>>
>
>
>-------------------------------------------------
>If you wish to unsubscribe from this list, please
>send an empty message to the following address:
>
>[EMAIL PROTECTED]
>-------------------------------------------------
>
>
>
>
>-------------------------------------------------
>If you wish to unsubscribe from this list, please
>send an empty message to the following address:
>
>[EMAIL PROTECTED]
>-------------------------------------------------
>
>
>


-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:

[EMAIL PROTECTED]
-------------------------------------------------




-------------------------------------------------
If you wish to unsubscribe from this list, please 
send an empty message to the following address:

[EMAIL PROTECTED]
-------------------------------------------------

Reply via email to