Java : Java related items, personal opinions, coding, etc.
Updated: 2/2/2004; 2:41:47 PM.

 

Subscribe to "Java" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.

 
 

Friday, January 10, 2003

Another potential issue with JDO type technologies...  If you are bringing back the whole object every time you query the database, aren't you doing the equivalent of a select *?  If that is the case, that is a known performance killer in applications.  Database application performance tuning usually starts with making sure you are only bringing back the columns you need when you need them.  If I'm having to instatiate the object will all the columns that are mapped to the object even if I'm only using a couple of those values, isn't that a huge performance hit?
12:55:47 PM    comment []

Here's a Java nuance.  If your method returns a value, a return statement must be guarenteed execution.  You can prevent the execution of a return statement by accidently including it in a  try-catch-finally block:

public boolean myMethod() {
 try {
  // Do some work
  return true;
 } catch (Exception e) {
 }
}

In the above example it's pretty obvious that if the work of the method before the return statement generates an exception, the return statement will not be executed.  The compiler will tell you that your method must return a value of type boolean.  So, you might think you can move the return statement to the finally block since the finally block is always executed.  You might write something like this:

public boolean myMethod() {
 boolean value = false;

 try {
  // Do some work
 } catch (Exception e) {
 } finally {
   return value;
 }
}

When you try to compile this code, you will find that the compiler is giving you the same error!  The problem is that if there is an exception that happens as part of the finally block, the execution of the return statement might still be circumvented!! 

Not good.  So, what's the right way?  Either move the return statement outside of the try-catch-finally blocks altogether, or return one value inside the try block before the first catch, and return a different value outside the try-catch-finally blocks.   The latter may be the more common and preferable situation since it allows you to return a "good" value if there are no errors inside the try block and if there are errors, you can return a "bad" value outside the try-catch-finally blocks.  Here's an example:

public MyClass myMethod() {
 MyClass obj = new MyClass();

 try {
  // Do some work

  // Return good value because there
  // were no errors.
  return obj;
 } catch (Exception e) {
  // Exception handling code
 } finally {
  // Clean up after errors
 }

 return null;
}

As you can see, making sure your method returns a value if it says it will can be a bit confusing.  However, like most programming problems, if you understand the language and think through it logically, you can find solutions that make sense given your needs. 

 


11:47:56 AM    comment []

I think I've stumbled upon a JDO anti-pattern.  I'm definitely a stranger in this part of town, so it's entirely possible I have no idea what I'm talking about.  I'm using Castor JDO in a project that I'm currently working on.  I'm going to try to explain the anti-pattern without using true pattern documentation format because I simply don't have the time.  So, here goes...

I need to update a single row in a table and change a flag column's value from 'Y' to 'N' or vice versa.  I'm noticing that there is more code that I have to write with Castor JDO vs. JDBC to perform this operation.  I have to get a database connection, issue a query, pull my object from the results, call a setter method to change the flag column's value, write the object back to the database.  With JDBC, I would get a connection to the database and issue an update query against the database.  I may do some checking to make sure that only 1 record is coming back (like a select count(*)), but not much more.

I can imagine this situation being even more involved as you update the column for a large group of records.  With JDO you would have to loop through the objects you get from your result set, set the value on each, and persist them back to the database.  With JDBC, you could still issue your update query and change your where clause a bit to get the records you want.

SO, my anti-pattern is that it takes alot more work to update a single column across one or more rows with JDO than it does with JDBC.  It seems to make more sense in these cases to use JDBC to do those types of updates.  However, it breaks the JDO paradigm and makes your code inconsistent.


8:27:47 AM    comment []

© Copyright 2004 Tom Pierce.



Click here to visit the Radio UserLand website.

 


January 2003
Sun Mon Tue Wed Thu Fri Sat
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Dec   Feb

Search

 
How this works

Emacs Sources
 tsql-indent.el
 user-add-sql-folding-marks
 remove-line-boundary-in-region
 convert-camel-to-underscore

My Subscriptions
 Funny
 KM