Dragan Milic

Originally posted by Pradeep Bhat:
Dragan SLSB cannot be reentrant.

Hi,
as usually i did NOT read carefully the question (especially the NOT part of it ). So, forget what I said

Dragan

Originally posted by Pradeep Bhat:

Entity beans can be reentrant. IN MDB reentrant does not make sense because client cannot directly invoke the bean but the container does and container makes sure that no more than one request is made to a bean.

Just a note on the SLSB: IMHO reentrant SLSB is an oxymoron, since the container can use only one SLSB per business method call.

Dragan
[ August 29, 2003: Message edited by: Dragan Milic ]

I've just checked at the certmanager - passed with 84% - not that bad for 8 days of prep and taking the exam on the first day Thanx to Kathy for a great tips on the beta, and to all others for the posting here - without that my score would be at least 15% lower

Dragan

Originally posted by Chris Mathews:
Actually, the EJB Specification explicitly makes a point of not specifying the transactional context for the ejbCreate() lifecycle event of Session Beans (and a few other lifecycle methods). Some Application Servers may allow you to begin a transaction in ejbCreate(), others may not. Therefore, attempting to start a transaction in ejbCreate() of a Session Bean should be avoided if you are looking to create a portable solution.
For more information on this, see 17.6.5 of the EJB 2.0 Specification.

Hallo Chris,
Starting a transaction in the ejbCreate() of the SLSB makes no sense since the instances are pooled. Starting a transaction in the ejbCreate of the SFSB makes sense and is allowed by the EJB 2.0 spec. See the Chapter 7.6.1 (page 80, table 2 - BMT Demarcation).
Dragan

Originally posted by Akasmat de Goa:
Sorry , let me elaborate
What i meant is does the JVM perform any optimizations on the method getClass() declared as final in java.lang.Object at runtime so that the cost of calling the getClass() method a number of times is nullified ?
e.g Does the JVM already have the class name in memory (when the class loader loads the class) or something to that effect so that my calls to getClass() would be optimized -- which in turn would make it more efficient to use rather than the second way i.e Assigning getClass() to a final variable and using that variable thereby precluding calls to getClass().getName().

Hallo Akasmat,
optimizing the calls to class.getName() are probabbly the last optimization one should make, I ran some Tests with 2000000 calls to getClass() withing a loop and an empty loop - results are (Pentium III, 1GHz, Linux - Redhat 8.0, SUN JDK 1.4.2)
2M calls to getClass() within the for() loop: 2381ms
2M for() iterations witout calls to getClass(): 2368ms
So, You can forget the performance issues here. You can code it either way without noticing any difference.
BTW What does Your question has to do with SCBCD?
Dragan

Originally posted by Valentin Crettaz:
Switzerland ?

I took the exam in Switzerland.
Dragan

Originally posted by Terry McKee:
So does Home refer to a deployed location? If I have two servers that are part of the same application and an EJB is deployed on both of the servers - there would be two distinct home(s)?

Hi Terry,
Every EJB application consists of N Beans (Sesson, Entity, MDB). Each of those Beans (with exception of MDBs) gets a Home associated with it at the deployment time (that Home implements the home interface of the bean). This "home" is not location (host) dependent, it is EJB-Application dependent. That means you can have one "Home" that exists on 20 clustered servers or you can have many homes on one server. The home is a factory for the beans, so you can say that beans created by the same factory are equal if their primary keys are equal.
Dragan

Ok, I took the exam today (1.5 hours ago), here is my report:
The duration of the exam: 4 Hours
Number Of Questions: 183
Topics: Everything covered by EJB 2.0 spec except BMP Entity Beans (BMP are my favorite Entity Beans (()
It took me 3.5 hours to answer them all (for the comparsion: i needed something like 55 minutes for the part I of the SCEA, but i was better prepared for the SCEA)
The most of the Questions were not very hard (of course there are exceptions, for example there was one EJB-QL Question that could be used in a IQ-Test). Some of them were tricky - expect that answers to some of the questions are not very obvious (well, just like in the SCJP Exam)
As far as i could see, it i VERY important do know the responsibilities of the EJB-Roles (Deployer, App. Assembler, ...), the lifecycle of the beans (Session, Entity, MDB) - it is very helpfull if you can memorize the state diagrams of the beans. There were many questions about EJB-QL, session beans, MDBs, CMR, CMP and CMT, and fewer about Transactions, Securty, Interoperability and Exception-Handling.
Just another warning about the test:
There is no way to review the D&D Questions - if you try it you must answer the whole question from scratch! If you are not sure about some D&D Question, write down what you have entered so that you can reconstruct it on a review.

Dragan

Originally posted by Kalpesh Soni:
I did not want to take ANY chances, so just scheduled my exam on this saturday, 6th june

Hi, I hope you scheduled your exam for the friday 6th june. The next saturday 6th june is in 2009 . Anyway, I also scheduled my exam for the 6th.
Kathy are you really sure that first 400 exams are not going to be taken on the first three business days?
Dragan

Originally posted by Seid Myadiyev:
Hi Dragan,
This option states:
"Using the 'final' modifier for fields."
-- for fields -- I took it literally.
+Seid

Oops, sorry ... i didn't read carefully.
Dragan

Originally posted by Andrew Perepelytsya:

B, C - these are valid Java constructs that have no restrictions for EJB.

Not Quite, 7.10.4 in the spec: "The method must not be declared as final or static.". The reason is that the container should be able to extend your class (to generate the code for a security, transaction, activation etc. handling). I suppose that EJBs with final business methods would work in jboss since they do not generate a class extending your bean, instead of that they use proxys.
Dragan

Originally posted by karthik Guru:
In Page 347 of the spec, they have given an example wherein a Session bean holds on to a transaction w/o commiting over multiple methods.
method1() does a begin()
and then method3 does a commit finally.
Now the spec also says that a business method in a stateless session bean must commit a transaction before it returns. Is'nt method1() supposed to do a commit before returning?
Does this mean that the bean they are referring to in the code is "Stateful" and NOT "Stateless"?
Or am I missing something?
thanks!

Hallo karthik,
the code Example on the page 347 is for a SFSB. There is nowhere in the Text a statement that it is a SLSB.IMO The code on the page 374 is a variant of the code on the page 345, for that code example is explicitly stated that it is a SFSB.
Dragan

Dragan

Originally posted by Kathy Sierra:
QUESTION ONE:
Match the operation in list ONE with the method in list TWO in which that operation can be performed, for a stateful session bean:
LIST ONE: Operations (things you want to do)
1) invoke the SessionContext.setRollbackOnly()
2) invoke the UserTransaction.setRollbackOnly()
3) access this bean's own EJBObject interface
4) access this bean's own home interface
5) access a reference to another EJB

LIST TWO: Bean methods in which the operations from list one can be performed:
A) ejbCreate
B) afterBegin
C) business method
D) setSessionContext
E) afterCompletion
Note: There *may* be more than one correct answer!

Ok, i hope i won't mess up this time
1 - B,C (May be called only if there is a transaction context and CMT is used).
2 - A,C (B is not possible since BMT does not support SessionSynchronization interface)
3 - A,C or A,B,C,E depending on Transaction management BMT or CMT (according to the spec there is no SFSB identity at the time the method setSessionContext() is called)
4 - A,C,D or A,B,C,D,E also depending on transaction management BMT/CMT: You can always (Except in the bean constructor) access the EJBHome.

5 - A,C or A,B,C (BMT/CMT): In the afterCompletion() method there is no transactional context, setSessionContext() has no caller identity.
Dragan

Originally posted by Pradeep Bhat:
Answer for first one D,E AND G.

You are right, I forgot to change C in E after re-reading the chapter 17 of the spec.
Dragan
[ May 26, 2003: Message edited by: Dragan Milic ]

Hi Kathy,

Originally posted by Kathy Sierra:
Q1: Which three are true about transactions in EJB?
(Choose three.)
A) EJB 2.0 supports nested transactions.
B) EJB 2.0 allows you to specify isolation levels.
C) Message-driven beans must not use bean-managed transaction demarcation.
D) Entity beans must not use bean-managed transaction demarcation.
E) Stateful session bean state will not be rolled back if the transaction rolls back.
F) Stateful session beans that start a transaction must complete the transaction before ending a business method.
G) A message-driven bean must commit or rollback a transaction before onMessage returns.

IMO The Answer is C, D and G.
A - EJB 2.0 supports no nested transactions (see ejb 2.0 spec 17.1.2)
B - EJB 2.0 specify no isolaton leves (17.3.2 in the spec)
C - MDBs can use BMT, but must commit or rollback the transaction before returning from the onMessage() method (17.3.3).
D - Only MDB and Session Beans can use BMT (17.3.3)
E - It would be very expensive to implement such behavior in the container - The session should be passivated and stored on the start of the transaction, and reactivated on rollback - that would be a major performance killer ... also the SessionSynchronization interface would not make much sense.
F - SFSB can start a Transaction in one and end it in another business method, SLSB must end the transaction in the same business method.
G - It would not make sense to leave the transaction unfinished, MDB can be seen as a special case of a SLSB where the method invocator is a queue or a topic. See also (17.3.3). BTW This possibility is a bit vague, in the case of the CMT the MDB cannot commit or rollback the transaction (it can only mark it as rollback only or throw the EJB Exception)

Q2: Which two are true about bean-managed transaction demarcation?
A) A transaction used by a BMT bean MUST have been started by the bean.
B) The caller's transaction will be propogated into a BMT bean.
C) Transactions in a BMT bean do not propogate when the BMT bean calls a method on another bean.
D) A bean cannot use both CMT and BMT together.
E) BMT beans must not specify transaction attributes.

A, D, E
A - Since the bean manages the transactions, it must also start them.
B - That would be a conflict with the 17.1.2 - nested transactions are not supported by EJB 2.0
C - BMT and CMT are threated equally when a method on another bean is called (this option is also vague, the caller's transaction will will be suspended if the business method on another specifies RequiresNew or NotSupported transaction attribute)
D - It is not possible to define CMT or BMT on method basis - only for the whole bean
E - transaction attributes are specified only for CMT, see 17.3.6 and 17.4.1

BTW Kathy, 10x for investing your time and energy in our cert preparation, you are doing a great job!
Dragan