tuesdayDeveloper;

New Home

2009-12-11T20:23:00.000-08:00

Hey everyone,

tuesdayDeveloper has found a new home. If you are reading this you will probably be forwarded shortly, if not click here.

Lazy vs. Eager in Java EE

2009-12-09T10:29:00.001-08:00

So you have a relational database and you want to see what Addresses, Phone numbers, or Accounts are associated with a Person. By default, Java EE will only get the objects it absolutely needs; this is called lazy fetching. So solve this problem you want to fetch eagerly. In your code, find the attribute in your entity bean that you want to eagerly fetch and edit the attributes to indicate that it should eagerly fetch the information:

In the Person bean:

@OneToMany(mappedBy="person", fetch=FetchType.EAGER)

private Set accounts;

Query Without Primary Key in Java EE

2009-12-09T10:25:00.000-08:00

It is extremely simple to get an entity bean object from a database based on the primary key:

public Person getPerson(String personId) {

Person aPerson = manager.find(Person.class, personId);

return aPerson;

}

But what if you don't have the primary key, like when you want to log in and you only have the userid and the password?

For this you will need to actually write a query, but do not fear, it is very simple:

public Person getPerson(String userid, String password) {

if(userid == null || password == null) {

return null;

}

try {

Query q = manager.createQuery("select p from Person p where p.userid = :uid and p.password = :pass");

q.setParameter("uid", userid);

q.setParameter("pass", password);

Person aPerson = (Person) q.getSingleResult();

if(aPerson == null) {

return null;

}

return aPerson;

}

catch (Exception e) {

return null;

}

Comparing Two Collections

2009-12-08T18:31:00.000-08:00

This is a valuable piece of code that I am sure I'll be using in the future:

    public boolean isSame(Collection expected, Collection actual) {
 /* first compair the sizes, if they are not the same there is no use in going further */
     if(expected.size() != actual.size()) {
      return false;
     }
 /* the count variable will increment for each match */
     int count = 0;
 /* The iterators check each object in each Collection */
     for (Iterator iterator = expected.iterator(); iterator.hasNext();) {
   Object object = (Object) iterator.next();
   for (Iterator iterator2 = actual.iterator(); iterator2.hasNext();) {
    Object object2 = (Object) iterator2.next();
    if(object2.equals(object)) {
     count++;
    }
   }
  }
 /* the count variable is the same as the size of the Collections then all items match */
     if (count != expected.size()) {
      return false;
     }
     else {
      return true;
     }
    }

I wrote it to check if and expected Set was the same as an actual Set. I chose to use a Collection to make it more generic, and since a Set is a Collection it will still work.

Connecting Entity Beans to Set/Retrieve Data

2009-12-07T17:45:00.000-08:00

I've spent the last week figuring this out, ultimately I had one line that was wrong.

When you have the database set up, and the entity beans in an EJB project, how do you connect to the server to access or update data?

Prerequisites: You should have entity beans in an EJB Project that reference a database.

You should have two classes set up in your EJB project: BusinessRules.java, BusinessRulesRemote.java (or whatever you chose to call them). These files have a special method to construction, follow the list below.
1. Secondary click the EJB project and select New > Session Bean
2. Enter the package and class name (I chose "session" and "BusinessRules")
3. If you want to use a remote interface (best for scalability) you will need to select it. You may leave the local interface (best for performance) button checked or you may uncheck it, I unchecked it.
4. Click finish.
Edit your BusinessRules.java and BusinessRulesRemote.java class.

Now you need to implement your business logic.
@Stateless /*These business rules are stateless.*/ public class BusinessRules implements BusinessRulesRemote { /*class header*/ @PersistenceContext /*If you are using Java EE then you will need this to get the Persistent context*/ EntityManager manager; /*The manager you'll be using*/ public static final String REMOTEJNDINAME = BusinessRules.class.getSimpleName() + "/remote"; /*JNDI name so that the class can be found*/ public BusinessRules() { //Default constructor }

Note: if you use @PersistenceUnit instead of @PersitenceContext it will not work.

You will need to have methods in the BusinessRules class in order to access your data. Here is an example of how to select a person using their primary key (continued from the code above):

 public Person getPerson(String personId) {
  Person aPerson = manager.find(Person.class, personId);
  return aPerson;
 }

After you do this you will just need to call an instance of your BusinessRules class (businessRules) and then call methods (e.g. businessRuless.getPerson("1");)

In order to get an Object Person as an entity from your database based on their username and password you will want to overload your method in BusinessRules (or just not use the former method since it isn't very practical) and write a query using EJB QL. Example (continued from code above):

public Person getPerson(String userid, String password) {

     Query q = manager.createQuery("select p from Person p where p.userid = :uid and p.password = :pass");
     q.setParameter("uid", userid);
     q.setParameter("pass", password);
     Person aPerson = (Person) q.getSingleResult();
     return aPerson;
    }

Resources: Sun, Enterprise JavaBeans 3.0 5th Edition 2006 Bill Burke & Richard Monson-Haefel

Reference: Data Isolation and Database Locking

2009-11-21T09:00:00.000-08:00

There are several problems that can occur on a relational database when muliple users are accessing the same data.

Dirty Read: (No, it's not a romance novel.) When a record is changed by "Person A" but hasn't yet been committed. "Person B" reads the data that hasn't been updated. It can also occur when "Person B" reads data that ins't committed to the database, if "Person A's" transaction is rolled back, the data that Person B has read is no longer valid.

Example: (numbers are indicative of time intervals) Two people share a bank account, "A" wants to pay a bill which requires the called method to debit and then credit their account record in the database.

1- "A" reads that there is $300 in his bank account.

2- "A" starts to pay a bill and his account is debited by $150

3- "B" looks at the account balance and reads that there is $150

4- An error occurs when "A's" transaction is processing the credit to the payees table and the transaction is rolled back. The account balance is now $300 again.

This is an example of a dirty read because the information that "B" has is no longer valid.

Non-repeatable Read: Is the same as a dirty read but it involves a second record call from the database, if the second time the same record different, it is a non-repeatable read. (Up until the data is changed, it is still a dirty read.)

Example: "A" and "B" share an account. "A" wants to pay a bill which requires the called method to debit and then credit their account record in the database.

1- "A" reads the account balance, $300

2- "B" reads the account balance, $300

3- "A" debits the account balance, it is now $150

4- "B" reads the account balance again and the value has changed

Phantom Read: When a record is deleted or a new record is added to a database that effects what another user is doing.

Example: "A" is a client for an online store, "B" is the manager for the store.

1- "A" reads that there is 3 widgets in inventory.

2- "B" receives a shipment and updates the inventory of the widgets to 5003

3- "A" hurries to by before there are none left, but when he is done there is over 5000 widgets in the store.

These problems call for transaction isolation. Transaction isolation restricts how users can access data in the database. There are four different levels for Java EJBs:

Read Uncommitted: This is the lowest level of isolation, it allows dirty reads, non-repeatable reads, and phantom reads. This level of isolation can be used when you are not worried about collisions in the data and you're willing to sort them out if any.

Read Committed: A transaction cannot read uncommitted data, a record (or a table depending on your DBMS) will be locked and that data cannot be read by other transactions. This prevents dirty reads, but allows both non-repeatable reads and phantom reads.

Repeatable Read: This level of isolation prevents one transaction from changing data that is being read by another transaction. This prevents both dirty reads and non-repeatable reads, but phantom reads can still occur.

Serializable: Only one transaction has read and write privileges at a time. This prevents all read/write problems, but may cause performance to be slow for its users.

Just like anything else, there is give an take with what is ideal and what can occur in an application that interacts with a database. In general I think that users are understanding that other users can have an effect on the data, but it is still something you should plan for. Perhaps if one user is viewing data that another user is updating it would be appropriate to indicate that there is something going on there so that the users understand why their transaction is taking so long, or at least to let them guess that their data may have changed.

Resources: Enterprise JavaBeans 3.0 5th Edition 2006 Bill Burke & Richard Monson-Haefel

Eclipse Hint: Clean Your Projects

2009-11-16T19:23:00.000-08:00

Earlier today when I was working on a project I took a look at one of my entity beans and it had all sorts of errors in it. Seeing as how I had Eclipse create these for me and I didn't edit the code or the database at all, I was a bit confused. When I looked at the project file listings I noticed that Eclipse said all of the beans had compile errors in them.

Naturally I restarted Eclipse to see if that would help, nope. I then went to Project > Clean and selected my EJB project, sure enough, all the errors when away.

Eclipse is a wonderful tool, but even the best tools have their moments.

Creating Java Entity Beans Dynamically from Database

2009-11-10T16:05:00.000-08:00

What to create your entity beans dynamically?

After you've created a new EJB Project in Eclipse and you have a database with tables, sequences, and relationships defined, it is quite easy to create your entity beans dynamically in Eclipse.

Ensure that the JPS Tools are enabled.
1. Right click the EJB Project folder and select properties
2. On the left hand side of the properties window, select Project Facits
3. Check the Java Persistence checkbox
Build the beans from the database.
1. Right click the EJB Project folder and select JPA Tools > Generate Entities from Tables...
2. Ensure you are connected with the correct server and schema
3. Select the entity beans you want in your project.
4. Don't for get to tell it which package you want the beans in.
5. Click next until it asks you for the sequences for each bean and enter in the appropriate sequence generators.
Click finish and it will build all the entity beans for you.

The project will then build the beans for you assuming you have all the appropriate relationships etc.

Resources: Kent Jackson (BYU-Idaho Professor)

(Configuration: Eclipse Galileo for Java EE 6 using JBoss Server on Mac OS X 10.6 connecting to a VMware virtual machine with Windows running an academic licence version of Oracle)

Disclaimer

2009-01-06T00:01:00.000-08:00

People, programs, or robots who connect, read, view, think about, converse about, index, transcribe, copy for assignments, or anyone else who has anything whatsoever to do with this blog must accept these terms or they are not allowed to view them. If any of these entities view this site or use the information in any way they agree to these terms.
This site is not responsible for damage, loss, or other ill effects to computers, networks, hardware, users, household items, industrial items, consumption goods, durable hardware, small children, or anything else that bad advice can harm. You take suggestions at your own risk. (That said, I'm not going to put bad advice on here if I can help it, I just don't want anyone suing me for saying that they did what I told them to and it didn't work, or it caused their computer to lose it's memory, or it caused them to go bald.)
Blog comments that are spam, crude, have vulgar language (even mildly vulgar), are offensive, or otherwise inappropriate will summarily be deleted.
Links from this blog are not affiliated with this site or its entities unless otherwise stated.
All content is copyrighted by the author of tuesdayDeveloper;

Welcome

2009-01-06T00:00:00.000-08:00

This is the inaugural post for the tuesdayDeveloper Blog.

I started this blog because I've spent too many hours looking for the solutions. The problem is those solutions are way too scattered, and when you do find the answers, they aren't always comprehendible. So I'm putting the answers here, in an easy to understand list, in one place, where anyone can find it. Sure, I can't find all the answers, I don't expect to—I don't expect that every developer out there will find this useful—I'm still in college after all—there are undoubtedly developers with years more experience than I have. I can still do my part, and I can still make a few lives easier. I think programming is fun, I want others to feel the same.

You might ask why I call it tuesdayDeveloper? Because I thought the title was catchy. There is no other significance to it than that.

What types of things will I be posting? Solutions to any question I may have while I'm programming.

If someone wants to ask me a question will I answer it for them? Sure, if anyone has questions or suggestion let me know and I'll do my best to help you.