E Lievaart

Well, I haven't written any native code, but I can't guarantee that the 3rd party libraries don't use any internally.
I have run the application on linux and windows, other OS I will not support, that is not to say that it (can't / won't) work.

I wrote a simple java based filebrowser. It has some useful features I have not found elsewhere.
I thought it could be interesting to some of you out there:
http://qfilebrowser.org/
https://bitbucket.org/Lievaart/q/downloads

I dont think you will be able to find anything like that.
Even reference implementations usually have a few off-specs

Well, the order is completely free, the exams are not linked.
I think SCBCD first is the best choice.
SCDJWS is one of the toughest exams out there.
Having SCBCD will help you... a little... There is a little bit of overlap.

First of all, I wouldn't start with reading the specification.
It is better to have some understanding of the material when you do.
If you are going for just one book you should choose between the O reilly book or Ejb in action.
In action seems to be the most popular choice here. I have the O reilly book.
Very few people will be able to compare them both
(because hardly anyone reads both)
Both books cover all aspects of EJB, but not in enough detail.
Honestly, passing the exam is going to be hard just reading one of these books.
Pro EJB Java Persistence Architecture is THE guide on JPA.
It will give you roughly enoug detail for the exam I think.
However, the scope is limited to JPA, and you need to know EJB3 as well.

Conclusion: 1) Use one of the books you listed, whichever you prefer.
2) Use additional references (exam sims, MZ guide in links section, specs, etc)

Hey Krishna,

My best guess here is that you get the exception due to a FK constraint.
In JPA it is the programmers job to ensure the references are valid.
Try setting the references to null after you merge, before you remove.
So set Employee.manager to null and remove the Employee from Manager.employees.

Hmm, that's strange since you're calling merge on it first.
It should be all right.

The entity does exist in the database right?
Does deleting the entity violate a FK constraint somewhere?

What happens if you use:
entity.remove(entity.getReference(emp.getPK()));

instead of:
entity.remove(entity.merge(emp));

Actually, you can be sure that there is a transaction.
No transaction attribute is specified on the class or on the calculateUserCount().
The default transaction attribute is REQUIRED.
In other words there will always be a transaction when the method is called.

Usually you would use transaction attributes to answer the question you asked.
It makes little sense to use an attribute of SUPPORTS
and then poll the transaction, because you actually need one.
I you want to ensure that the method is always called within an existing transaction, then assign an attribute of MANDATORY.

Since the bean is stateful you can use the SessionSynchronization interface as well.
This way you can monitor the transaction status.

Usually on exams, when sun asks: can the method be called?
Sun means: will the method call complete successfully?
The answer to the question is no, as far as I am concerned.

If you want to know the details, I suggest reading
Expert one on one ~J2EE Design and Development~ by Rod Johnson
http://www.amazon.com/Expert-One-Design-Development-Programmer/dp/0764543857/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1216497996&sr=8-1

I would not learn Groovy for the sake of professional culture.
Groovy is very interesting and I like it,
but as far as I know it isn't used much in enterprise applications.

I am not sure if Struts will always be there,
but it is probably the most applied framework out there.
It is small and easy to learn.
Struts is thus asked a lot on job listings.

I would advise Spring though. Spring is a whole different story.
Spring is the largest framework outside of J2EE (in functionality).
It is pretty much an alternative to the J2EE.
Spring has it's own Struts look alike included.
Subjects as dependency injection and AOP will require you to rethink software development.
This is very good for your professional culture.

Read JSF or adobe flex instead if you want to know how to develop web interfaces quickly.
[ July 18, 2008: Message edited by: E Lievaart ]

As far as I can see, in the first situation the container throws an exception,
because a method call with a transaction enters a bean with attribute NEVER.
This is not an error in bean B, but in the bean that calls it.
Bean A should not call bean B with a transaction.
It makes little sense to discard B, because it has done nothing wrong.
In fact, it has done nothing at all.

In the second situation bean B is invoked and something happens.
Bean B throws a system exception.
This is probably a resource problem or a programming error.
Since bean B might we corrupted it should be discarded.

The EJB container ensures that there is always only 1 Thread accessing an EJB.
Different threads may be directed to an EJB, but not simultaneously.
This is why you are not allowed to create threads or use synchronization.
It is the turf of the container.
Basically EJB's are similar to the Servlet single thread model.

Of course this doesn't relieve the programmer of any concurrent considerations.
For example:
Don't use instance variables (except resources) in stateless session beans.

First read a book about it to understand the topic.
Most here use EJB3 in action.
The book by O'reilly is a good alternative.
You might consider reading EJB3 pro ~Java persistence architecture~ as an additional resource on JPA.
After this first step you have a rough idea on the subject matter.

Next you need to use some exam specific material.
There is no exam drill kind of book, so your options are.
- Monitor this forum
- Read the EJB spec
- Read the Mikalai Zaikin guide
- Make mock exams
Just match and mix whichever methodology best suits your tastes.

For resources view the links section:
http://faq.javaranch.com/java/ScbcdLinks

They were
A) too complex for what they were trying to do.
B) did not perform well enough.
C) were not flexible enough to suit common needs.