Ok, for when I actually call it. I do the following:
try{
Class cmdCls = Class.forName(command);
Command com = (Command)cmdCls.newInstance();
parameters.put("db", db);
Object returnValue = com.execute(parameters);
return returnValue;
}catch(CommandException ce){
try{
if(db.isActive())
db.rollback();
}catch(TransactionNotInProgressException tnpe){
logger.debug("Transaction Error:", tnpe);
}
throw ce;
}
The CommandException is just a wrapper so I can use it as a general exception class.
Anyways, as you can see the call that would cause the exception is
"com.execute(parameters);" So, in side that other code that I posted before a
DuplicateKeyException gets thrown, which is just fine and dandy, and then it comes out
and goes into my catch block. So that’s the order of execution.
As far as what I'm testing, I'm just trying to make sure that any operations that I
will perform in my actual app on the persistence objects are valid. So in this case
I'm just adding a new Employee to the database which is related to a Department object
(hence the "db.update(user.getDepartment);")
My full code of execution is below for the command, also not that this works perfectly
when there is no DuplicateKey.
..import statements blah blah....
public class AddEmployee implements Command{
private static Logger logger = Logger.getLogger("com.vort.help.commands");
/** Creates a new instance of SaveEmployee */
public AddEmployee() {
}
public Object execute(java.util.Map params) throws CommandException{
logger.debug("Starting to create a new user.");
Database db = (Database)params.get("db");
if(db == null)
throw new CommandException("No \"db\" variable in parameters");
Employee user = (Employee)params.get("user");
if(user == null)
throw new CommandException("Need a \"employee\" variable in the
parameters.");
try{
db.begin();
db.update(user.getDepartment());
db.create(user);
db.commit();
}catch (DuplicateIdentityException de){
logger.error("There is already a user with this username in the
database.");
throw new CommandException("Employee already exists.", de);
}catch(PersistenceException pe){
logger.error("There was a problem saving the user." + pe.getMessage());
logger.debug("StackTrace:", pe);
throw new CommandException(pe);
}
return null;
}
}
So this is all the code that is touched when trying to run the command. Thanks for the
assistance Werner.
-Nick
-----Original Message-----
From: Werner Guttmann [mailto:[EMAIL PROTECTED]
Sent: Friday, March 12, 2004 2:25 PM
To: [EMAIL PROTECTED]
Subject: Re: [castor-dev] Rollback problem...
Nick,
can you make your statement 'but I have a section of code later on ' a bit more
explicit. Iow, when exactly are you calling Database.rollback() ? Could I see the
complete code ? I'd just like to make sure you get the exception handling right before
starting to dig deeper ...
Looking at your sample code below - if I may comment - I am getting the feeling that
in your testing drive you are asking a little too much .. ;-). Updating an object that
has been read during a separate transaction and creating a user object with the same
identity .. why bother testing this ? Iow, what is it that you are trying to test ?
Werner
On Fri, 12 Mar 2004 13:19:46 -0500, Nick Stuart wrote:
>
>I'm having a weird (at least to me) issue when trying to do a rollback.
>Basically during my tests I'm trying to insert a duplicate key, I catch and throw
>that error just fine, but I have a section of code later on that looks like:
> try{
> if(db.isActive())
> db.rollback();
> }catch(TransactionNotInProgressException tnpe){
> logger.debug("Transaction Error:", tnpe);
> }
>And when it gets to the db.rollback part I always get an the following error thrown:
>java.lang.NullPointerException: Adding null value is not allowed
> at org.exolab.castor.persist.FieldMolder.addValue(FieldMolder.java:274)
> at
> org.exolab.castor.persist.CollectionProxy$ColProxy.add(ClassMolder.java:3150)
> at org.exolab.castor.persist.ClassMolder.revertObject(ClassMolder.java:2565)
> at org.exolab.castor.persist.LockEngine.revertObject(LockEngine.java:852)
> at
> org.exolab.castor.persist.TransactionContext.rollback(TransactionContext.java:1720)
> at org.exolab.castor.jdo.engine.DatabaseImpl.rollback(DatabaseImpl.java:554)
> ....
>
>Is this what is supposed to happen, am I'm not supposed to try and do a
>rollback if I have a duplicate key error thrown? I can check for that
>easily
enough, but I though this was a more standard procedure.
>
>BTW, my commit code and everything is as follows:
>
> try{
> db.begin();
> db.update(user.getDepartment());
> db.create(user);
> db.commit();
> }catch (DuplicateIdentityException de){
> logger.error("There is already a user with this username in the
> database.");
> throw new CommandException("Employee already exists.", de);
> }catch(PersistenceException pe){
> logger.error("There was a problem saving the user." + pe.getMessage());
> logger.debug("StackTrace:", pe);
> throw new CommandException(pe);
> }
>
>Thanks for any assistance!
>-Nick
>
>---
>Outgoing mail is certified Virus Free.
>Checked by AVG anti-virus system (http://www.grisoft.com).
>Version: 6.0.619 / Virus Database: 398 - Release Date: 3/10/2004
>
>
>-----------------------------------------------------------
>If you wish to unsubscribe from this mailing, send mail to
>[EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
>
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a
subject of:
unsubscribe castor-dev
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.619 / Virus Database: 398 - Release Date: 3/10/2004
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.619 / Virus Database: 398 - Release Date: 3/10/2004
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
