This week's book giveaway is in the HTML Pages with CSS and JavaScript forum.
We're giving away four copies of Testing JavaScript Applications and have Lucas da Costa on-line!
See this thread for details.
Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!

Jef Kelly

+ Follow
since Jun 25, 2004
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jef Kelly

Wow...I passed the SCBCD exam with a 97%!

My primary study source was Head First EJB. I did one read-through, then a second to take notes. After that, I primarily used my notes to study, but the read-through provided a solid base of was just a matter of making the details stick.

I also used, Mikalai Zaikin's study guide (a little), and the various cheat sheets out well as LOTS and LOTS of searches on the Big Moose Saloon. THANK YOU GUYS!!!

16 years ago
So this is sort of "quiet rollback"...does this mean that the only way to really alert the caller is to always check getRollbackOnly() and throw an application exception (or return a success boolean)?
Thanks, Jason. I must admit it took me a few seconds before I slapped my forehead and said "Of course!"

I set up a PRIMARY_KEY table that looks (currently) like this:

1 207

I'm now creating an entity with only one business method, getEmployeePK(). It returns the value of EMPLOYEE_PK and then increments EMPLOYEE_PK. The bean has create methods, and ejbRemove calls setRollbackOnly to keep anyone from removing this one and only row. It seems like a good idea to make the trans-attribute mandatory to make sure that this whole process is part of the calling transaction.

Sound about right?

Is this sort of approach..."industry standard?"
Ok, I know this isn't on the exam, but I want to practice coding a few beans before I take the test, and I ran into a bit of a mire right out of the gate.

In the real world, is there an accepted or standard way of generating primary keys for entity beans?

Assuming a numeric PK...I've considered having a single go-to bean that reads the max value of the PK field in the database and then increments and doles them out. But if I do this as a bean, then every create() called on that bean's home is going to produce a bean that generates duplicates of every other bean in the pool! (more or less)

Static non-final field/method would seem to be an obvious bet, but they're disallowed.

Helper class? Vendor-specific dealie that I don't know about?

This seems like such a basic issue, but I haven't found any posts about it here....
I have an additional question about page 405.

The return type of the home business method is String. What if the query were to return more than one record? How would multiple directorIDs fit into a single string?
Okay, I'm going to be a jerk here for a minute, but only because I'm getting frustrated.

I've taken some time off from programming (used to to EJB 1 stuff back before the bubble burst), and I decided to get back into the game and "brush up" on EJB by getting this cert. I certainly know more now than I did even back when I was working with it, but going through the HFEJB section on CMP entity beans has finally lead me to ask myself this question:

Was the EJB team on crack when they came up with this stuff???

There's a lot of good to it, I know. But it seems as if they've created a lot of non-sensical arcane rules that need to be remembered in place of low-level programmatic "complexity."

My gripes du jour:
* regarding container callbacks: I thought it was generally understood that if you had two methods that behaved differently and produced different results, you didn't name them the same frickin' thing. They're not the same! They're not even overloaded! They're different!

* CMP creates: home interface returns component interface, bean class ejbCreate DECLARES pk object return but RETURNS null, and ejbPostCreate returns void. I understand why, but...why?

There are plenty more, but I don't want to spend all night whining. It's just that I've had to make up so many charts to keep the multitude of these little details straight that it makes me want to give up and go study something that makes sense to me as a programmer.

(sigh) But I won't.

And now I have to get back to studying.
I've hit the exception chapter of HFEJB, but the answers to the Sharpen Your Pencil exercises provided at wickedlysmart seem to peter out at transactions. I need reassurance!!!
Is there an EJBSharpenD.pdf? The last file peters out after page 497 in HFEJB. Is this final collection of answers in the works, unnecessary, or merely hidden from the unitiated?

Originally posted by Kathy Sierra:
Howdy all... just wanted you to know (whether you have the book or not) that we've posted both the Sharpen your Pencil PDFs and a jar of code to our site at:

Head First EJB page