SCBCD-5 Q&A With Explanations - 1

QUESTIONS FOR SCBCD 5.
0 FORM 1
Location: > Section 1: EJB 3.0 Overview > Objective 1.1 > Question 1
Which statement correctly identifies the goals of the designers of the EJB architecture?
A The EJB architecture requires that users be aware of the low-level transaction details of the Java EE
platform.
B The EJB architecture is the standard component architecture for building distributed business
applications in the Java programming language.
C Although the EJB architecture defines the contracts that enable tools to develop and deploy
components, each application server vendor needs to produce its own set of additional tooling.
D The EJB architecture provides a standard way of persisting state data using the Java Persistence API,
Java Data Objects, and JDBC.
Reference
Option B is correct. See section 2.1 "Overall Goals" in the Core Specification. None of the other options
are listed as goals here.
Option A is incorrect because the specification makes it clear that these low-level details are not
required.
Option C is incorrect because the developer does NOT need tooling from a particular application server
vendor.
Option D is incorrect because the EJB architecture only standardizes on the Java Persistence API
Which two APIs can be used to implement an EJB? (Choose two.)
A EJB 2.1 APIs
B EJB 3.0 APIs
C HTTP Servlet APIs
D File I/O APIs
E APIs for thread management
Reference
Options A and B are correct. (See 2.2 of the Simplifies Specification.)
Option C is incorrect because servlets are not used to implement enterprise beans. They can be clients
of beans, but they are NOT used in the implementation.
Options D and E are incorrect because the developer should NOT use thread management/file I/O APIs.
(See 21.1.2 of the Core Specification.)
What programming restrictions are defined in the EJB specification?
A An enterprise bean must NOT use the java.io package to attempt to access files and directories.
B A session bean must implement the javax.ejb.SessionBean interface.
C An enterprise bean must NOT declare any static fields.
D An entity bean class must be NOT be defined as public.
Reference
Option A is correct. (See 21.1.2 of the Core Specification.)
Option B is incorrect because the developer does NOT have to implement it. (See 4.6.2 of the Core
Specification.)
Option C is incorrect because it can use static fields as long as they are read only. (See 21.1.2 Core
Specification.)
Option D is incorrect because it must be public (See 10.2.2 of the Core Specification.)
The developer has been supplied with an ejb-jar file and now need to have this ejb-jar integrated and
deployed as part of a larger application.
Which two roles, defined by the EJB architecture, would play a part in this process? (Choose two.)
A Enterprise Bean Provider
B Application Assembler
C Deployer
D EJB Server Provider
E System Administrator
Reference
Options B and C are correct. See Core Specification 2.2. The assembler is responsible for combining
enterprise beans and the deployer for deploying them.
Option A is incorrect because the developer is provided with the ejb-jar file. Enterprise Bean Providers
provide enterprise beans.
Option D is incorrect because this refers to (typically) an OS vendor or middleware vendor.
Option E is incorrect because this role refers to someone who configures the enterprises computing and
network infrastructure.
Location:> Section 1: EJB 3.0 Overview > Objective 1.5 > Question 5
An Application Assembler wants to create an enterprise application archive file that contains two ejb-jar
files (ejb-jar1 and ejb-jar2). ejb-jar2 makes calls to the enterprise bean in ejb-jar1. ejb-jar1 has an ejb-
client-jar, myclient1-jar.
What is an appropriate way of packaging these assets into an enterprise application archive?
A There are too many dependencies, and the developer cannot create an archive with these
requirements.
B Package all three jar files in the archive, with appropriate metadata to link them.
C Package myclient1-jar as part of ejb-jar1, and ejb-jar1 and ejb-jar2 in the enterprise application
archive.
D Package ejb-jar1 as part of myclient1-jar, and the resulting myclient1-jar together with ejb-jar2 in the
enterprise application archive.
Reference
Option B is correct. See Chapter 20 in the Core Specification. In particular 20.4, 20.5 and 20.6.
Option A is incorrect because B is correct.
Option C is incorrect because ejb-jar2 needs to call ejb-jar1 and needs access to the client classes.
Option D is incorrect because the developer does NOT package ejb-jar files as part of a client jar.
Which statement is an accurate description of how annotation metadata and descriptor metadata are to
be used together?
A Deployment descriptor metadata can only be used to modify annotation metadata.
B A deployment exception is thrown if deployment descriptor metadata and annotation metadata

describe the same class, method, or field.
C Metadata annotations can be used as an alternative to deployment descriptors in most cases.
D Annotation metadata can only be used to modify deployment descriptor metadata.
Reference
Option C is the only accurate description. See the Simplified Specification 2.1.
Option D and A are incorrect because there is no requirement that only one set of metadata must be
used to modify the other.
Option B is incorrect because there is no requirement that the two types of metadata are independent.
They can both describe the same item.
Location: > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.1 > Question 7
Which two statements correctly identify when life-cycle callback methods on enterprise beans can be
used? (Choose two.)
A Stateful session beans support the PostConstruct, PreDestroy, PostActivate and PrePassivate lifecycle
callbacks.
B Message-driven beans support the PostConstruct, PreDestroy, PostActivate and PrePassivate life-
cycle callbacks.
C Stateless session beans support the PostConstruct and PreDestroy life-cycle callbacks.
D Entities support the PostConstruct and PreDestroy callbacks.
E Stateless session beans support the PostActivate and PrePassivate life-cycle callbacks.
Reference
Option A is correct. See Simplified 5.1.4.
Option B is incorrect because message-driven beans only support PostConstruct/PreDestroy (See

Simplified 6.1.3.)
Option C is correct. See Simplified 4.1.4.
Option D is incorrect. See Persistence 3.5.1.
Option E is incorrect. See 4.1.4.
Given the following session bean:
10. @Stateless
11. @Interceptors(MyOtherInterceptor.class)
12. public class MyBean ... {
13.
14. @ExcludeDefaultInterceptors
15. @Interceptors(MyInterceptor.class)
16. public void someMethod() {
17. }
18. }
Assume that no descriptors are used.
Which interceptor classes are called when someMethod() executes?
A No interceptor classes are called.
B MyInterceptor.
C MyOtherInterceptor.
D MyOtherInterceptor and MyInterceptor.
Reference
Option D is correct, see 12.7 in Core Specification. The ExcludeClassInterceptors annotation was not
used, but ExcludeDefaultInterceptors, which in this case does nothing because there is nothing in the
descriptors. Options A, B, and C are incorrect. Both classes are called, as described in Option D.
Given the following code snippet taken from a stateless session bean CrumbleBean:
1. package apple;
2. // ..
10. @Stateless public class CrumbleBean implements Crumblee {
11. @Resource int dough;
12. //...
20. }
What JNDI name must correspond with the field named dough?
A dough
B java:comp/env/apple.CrumbleBean/dough
C apple.CrumbleBean/dough
D java:apple.CrumbleBean/dough
Reference
Option B is correct. See 16.2.2 of Core Specification., first bullet. Remember these environment
resources are located in the java:com/env space.
Options A,C,D are incorrect because B is correct, per the specification.

Given the following excerpt from a stateless session bean:
10. @Stateless
11. public class OvenBean implement Oven {
12. @Resource SessionContext ejbContext;
13. @Timeout
14. @TransactionAttribute(REQUIRED)
15. public void ping(javax.ejb.Timer timer) {
16. // line 16
17. ejbContext.setRollbackOnly();
18. }
19. // .. more methods here ..
99. }
Assume that a timer is set up and initiated for this bean.
What happens when the timer expires (that is, after the time specified elapses)?
A Nothing happens.
B The method ping is called only once.
C The method ping is called at least twice.
D An exception is thrown because of the transactional attribute set on the method
Reference
Option C is correct. The method ping, which is set up as a valid time out method because of the
@Timeout annotation, is called at least twice and is valid with a REQUIRED transaction attribute. It is
called once, when the time expires. The container then rolls back the transaction (because of the call to
setRollbackOnly), rescinding the timeout. It is called at least once more (and is, when run on Glassfish)
according to the Core Specification 18.4.2.
Option B is incorrect because the specification states that the container should retry the timeout.
Options A and D are incorrect because the code is valid and executes correctly.
Given the following session bean:
10. @Stateless
11. public class OvenBean implements Oven {
12. @Resource SessionContext ctx;
13. public void heat() {
14. TimerService t = (TimerService) ctx.lookup("java:comp/TimerService");
15. Collection c = t.getTimers();
16. Timer tee = t.createTimer(1000, null);
17. }
18. @Timeout
19. void foo(Timer t) {
20. ctx.lookup("HiThere");
21. }
22. // more methods here
99. }
Here, the method heat is a business method of the bean. A remote client invokes the heat method of an
instance of this bean. What happens when this method is invoked?
A An exception is raised on line 19, some time after the heat method is invoked.
B An exception is raised on line 14.
C The method returns, and some time later foo is invoked because of the timeout.
D An exception is raised on line 16 because this is NOT a valid use of the timer service.
E An exception is raised on line 15.
Reference
Option B is correct. This code uses the SessionContext.lookup method, not a lookup on an InitialContext.
As such, it does NOT find the timer service here.
Option A is incorrect. The ctx variable is initialized. The lookup returns null. Of course, this method never
gets invoked though because of B.
Options C, D and E are incorrect. If t was bound to a valid TimerService instance, it would be fine.
Passing in this would be fine too, because the bean implements Serializable. (See 18.2.1 of the Core
Specification)
Which statement about EJB 2.x and EJB 3.0 interoperability is correct?
A A client of a stateless session bean written to the new EJB 3.0 API cannot be a client to a stateless
session bean written to the EBJ 2.1 API.
B EJB clients can access only EJB 3.0 entities and EBJ 2.0 entity beans together if transactions are NOT
used.
C A client of a stateful session bean written to the new EJB 3.0 API cannot be a client to a stateful
session bean written to the EBJ 2.1 API.
D Existing EJB 2.1 beans must be supported to run unchanged in EJB 3.0 containers.
Reference
Option A is incorrect. It can be a client of an EJB 2.1 component. See 9.2.2 of the Simplified Specification.
Option B is incorrect. You can use transactions. See 9.2.3 of the Simplified Specification.
Option C is incorrect. It can be a client of an EJB 2.1 component. See 9.2.2 of the Simplified Specification.
Option D is correct. See 9.1 of the Simplified Specification.
Location: > Objective 3.1 > Question 13
Which statement characterizes stateless session beans?
A They allow the PostActivate, PostConstruct and PreDestroy life-cycle callbacks
B They require home interfaces.
C Stateless session beans typically execute on behalf a single client.
D They are asynchronous message consumers.
Reference
Option A is incorrect. The developer cannot use PostActivate on a stateless bean. (See 4.1.4 of the
Simplified Specification.)
Option B is incorrect. Session beans do NOT require home interfaces. (See the Simplified Specification
3.5.)
Option C is correct. (See 2.4.1 of the Core Specification.)
Option D is incorrect. Message-Driven beans are asynchronous message consumers. (See 2.4.2 of the
Core Specification.)
A business interface for a stateful session bean is defined as follows:
5. public interface MyI {
6. public Set go(Set s);
7. }
Given an excerpt from a stateful session bean that implements this business interface:
10. @Stateful
11. public class MyStatefulBean implements MyI {
12. public Set go(Set s) {
13. s.add("Goodbye");
14. return s;
15. }
50. }
No deployment descriptors are used. A client has a reference to an instance of this stateful bean in the
variable foo, and executes the following code:
60. Set s = new HashSet();
61. s.add("Hello");
62. foo.go(s);
63. s.add("Gut");
What is the value of the set s after this code has executed (at the end of line 63)?
A "Hello"
B "Hello" and "Gut"
C "Hello" and "Goodbye" and "Gut"
D "Goodbye" and "Gut"
Reference
Option C is correct. MyI is actually a local interface because no explicit @Local or @Remote annotation
is present, and its the only interface implemented by the bean. (See 3.2 of the Simplified Specification.)
As a result, pass-by-reference semantics are used (See 3.2.2 of the Core Specification). Consequently, all
values are added to the same set, and so C is correct.
Options A, B, D are incorrect because C is correct.

A programmer is trying to get the following stateless session bean to compile:
10. @Stateless
11. public class StatelessSessionBean
12. implements StatelessSession, SessionSynchronization {
13. @Resource SessionContext ejbContext;
14. @EJB MyStatefulLocal ms;
15. Socket soc;
16. public void finalize() { /* do something */ }
17. public void foo() { /* do something */ }
18. public void fandango() { /* do something */ }
19. @PreActivate
20. public void foop() { /* do something */ }
21. private int myHelper(int x) { /* do something */ }
22. }
The StatelessSession interface looks as follows:
30. @Remote
31. public interface StatelessSession {
32. public void fandango();
33. public void foo();
34. }
Which two lines in the session bean implementation contravene the programming restrictions laid out
for session beans? (Choose two.)
A Line 12
B Line 13
C Line 16
D Line 15
E Line 21
Reference
Option A is correct, it is a fault. The programmer cannot implement SessionSynchronization in a

stateless bean, only in a stateful one. (See 4.5 of the Core Specification.)
Option C is correct, it is a fault. The programmer should NOT implement the finalize method (See 4.6.2
of the Core Specification.)
For the incorrect answers, Option B is NOT a fault. There is nothing wrong with this resource
declaration. Option D is NOT a fault either. There is nothing wrong with having a Socket here (there are
items that the developer cannot do with it though, see 21.1.2 of the EJB Core Specification). Finally,
Option E is NOT a fault. There is nothing wrong with having a helper method defined. (See 4.6.2 of the
A stateful session bean can receive a number of life-cycle callbacks during its lifetime.
Which order is a valid reflection of the order of life-cycle callbacks for a single stateful session bean?
A PreDestroy, PreActivate, PostActivate, PostConstruct
B PrePassivate, PostConstruct, PostActivate
C PostConstruct, PrePassivate, PostActivate, PreDestroy
D PostConstruct, PostActivate, PrePassivate, PreDestroy
Reference
Option A is incorrect because the developer cannot do anything much until after PostConstruct. The
developer certainly cannot destroy/passivate the bean before it is constructed. (See 4.4 of the Core
Specification.)
Option B is incorrect because the developer cannot do anything until after PostConstruct. The developer
certainly cannot passivate the bean before it is constructed. (See 4.4 of the Core Specification.)
Option C is a correct order. (See 4.4 of the Core Specification.)
Option D is incorrect because it cannot PostActivate before a PrePassivate. (See 4.4 of the Core
Specification.)
Location :> Objective 3.5 > Question 17
A stateful session bean contains the following business method:
9. @WebMethod
10. public void resetVal(String value) {
11. Context ctx = new InitialContext();
12. String oldVal = (String) ctx.lookup("java:comp/env/val");
13. ctx.rebind("java:comp/env/val", value);
14. }
What happens when this method executes?
A The old value for val in the environment context is replaced with the new value.
B The old value is NOT changed and the method simply exits without normally.
C A javax.naming.OperationNotSupported exception is generated.
D An exception is raised on line 11 when a new context is created.
Reference
Option C is correct because session beans only have read-only access to their environment. All the other
options are incorrect because of this. (See 16.4.4 of the Core Specification.)
Which statement about exposing session beans as web services is correct?
A The methods in a session bean exposed as web service operations should declare the methods to
throw java.rmi.RemoteException.
B If a bean implements a web service, it must explicitly define a web service interface.
C Methods of a session bean exposed in a web service can be transactional.
D Methods of a session bean exposed in a web service cannot have method permissions set.
Reference
Option A is incorrect. They should NOT. (See the Simplified Specification 3.3.)
Option B is incorrect. It does NOT have to. It can use @WebMethod instead. (See 4.1.1 of the Simplified
Specification.)
Option C is correct. See 13.3.6 of the Core Specification.)
Option D is incorrect. They can. (See 17.3.2 of the Core Specification.)

A client tests two stateful session bean business interface references for identity using the equals
method as follows:
10. @EJB Sfb fee;
11. @EJB Sfb fi;
12. if (fee.equals(fee)) { /* some code */ }
13. if (fee.equals(fi)) { /* some code */ }
Which statement is true about this testing?
A The test on line 12 always succeeds with true, but the test on line 13 always fail with false.
B Both tests always succeed with true.
C The developer should NOT compare business interface references with the equals method.
D The tests on line 12 and 13 both always return false.
Reference
Option A is correct. Each bean has a unique identify, so 13 fails. (See 3.4.5.1 of the Core Specification.)
Option B is incorrect because A is correct (so line 13 will fail)
Option C is incorrect because the specification allows such comparison.
Option D is incorrect because A is correct (so line 13 will fail).
Given an excerpt from a message-driven bean implementation:
@MessageDriven()
public class DeliveryBean implements javax.jms.MessageListener, javax.ejb.MessageDrivenBean {
public void onMessage(Message msg) { /* ... */}
public void setMessageDrivenContext(MessageDrivenContext c) { /* ... */ }
public void ejbRemove() { /* ... */ }
@PostConstruct
public void openDoor() { /* ... */ }

Which statement reflects a valid order of method invocation that the developer could find in the
lifetime of an instance of this bean?
A onMessage, setMessageDrivenContext, openDoor, ejbRemove
B openDoor, setMessageDrivenContext, onMessage, ejbRemove
C setMessageDrivenContext, openDoor, onMessage, ejbRemove
D setMessageDrivenContext, onMessage, ejbRemove
Reference
See 5.4.8 the Core Specification.
Option C is correct.
All other options are incorrect because C is the correct order. (See 5.4.8 of the Core Specification.)
Which statement is correct about message-driven beans?
A Message-driven beans cannot hold state in their instance variables across the handling of multiple
client messages.
B References to message destinations can be injected, but not looked up in the JNDI namespace.
C A message-driven bean does NOT need to implement a message listener interface.
D Message-driven beans are anonymous. They have no client-visible identity
Reference
Option D is correct. (See 5.1 of the Core Specification.)
Option A is incorrect. They can. (See 5.1 of the Core Specification.)
Option C is incorrect. It does need to, for the appropriate message type. (See 5.4.2 of the Core
Specification.)
Option B is incorrect because they can be looked up in JNDI. (See 5.4 of the Core Specification.)
Which statement is correct about the delivery of messages to a message-driven bean?
A Message-driven beans should be coded to be reentrant.
B The container serializes all calls to a message-driven bean instance, including message listener calls
and any callbacks.
C The container only allows a single instance of a message-driven bean of any one type to be executing,
and serializes any additional incoming messages to this instance.
D All messages are delivered to message-driven beans in the same order in which they are sent.
Reference
Option A is incorrect. They do NOT because the container serializes requests. (See 5.4.10 of the Core
Specification.)
Option B is correct. (See 5.4.10 of the Core Specification.)
Option C is incorrect. A container typically maintains a pool, allowing concurrent execution. (See 5.4.11
of the Core Specification.)
Option D is incorrect. No guarantees are made about the order.
Which statement is true about a JMS message-driven bean and its clients, assuming that the message-
driven bean uses container-managed transactions?
A Clients can access the message-driven bean through its business interface.
B If a client sends a message to a message-queue that has the message-driven bean configured to listen
on that queue with an auto-acknowledge mode, then the client must wait for an acknowledgment after
sending the message before sending another.
C Clients cannot receive exceptions from the message-driven bean.
D Message-driven beans are multi-threaded and so can process multiple messages from different
clients at the same time.
Reference
Option A is incorrect. They do NOT have a business interface. They are decoupled from their clients. (See
5.3 of the Core Specification.) Rather, clients talk to a destination or endpoint, NOT a bean.
Option B is incorrect. JMS is asychronous.
Option C is correct. They cannot. (See 5.4.17 of the Core Specification.) The container actually takes the
bean to a does-not-exist state and assigns other instances to the destination.
Option D is incorrect. They are single-threaded and can process only one at a time. A container pools
instances of them, allowing concurrent execution. (See 5.4.11 of the Core Specification.)
Location: > Section 5: Java Persistence API Entities > Objective 5.1 > Question 24
Which statement about entities is correct?
A Entities must be annotated with the @Entity annotation.
B Entities can be final classes.
C Entities can have a single no-arg constructor with protected visibility.
D Instance variables of an entity can have private, protected, public, or package visibility.
Reference
Option A is incorrect. The developer can use the XML descriptor instead. (See 2.1 of the JPA
Specification.)
Option B is incorrect. They cannot be final. (See 2.1 of the JPA Specification.)
Option C is correct. That no-arg constructor can be protected, it does NOT have to be public. (See 2.1 of
the JPA Specification.)
Option D is incorrect. They must NOT be public. (See 2.1 of the JPA Specification.)
Given an excerpt from a simple class:
5. public class Foo implements Serializable {
6. String s;
6. }
And given an excerpt from an entity that references this class:
10. @Entity
11. public class Bar {
12. @Id private Integer id;
13. @Transient Integer moo;
14. @Temporal(TemporalType.DATE) java.sql.Date doo;
15. @Lob @Basic protected Byte[] bits;
16. @Basic(fetch=FetchType.EAGER, optional=true) private Integer goo;
17. transient int soo;
18. /* ... */
19. }
Which line in the Bar class causes this class to NOT be a valid entity class?
A 13
B 14
C 15
D 16
E 17
Reference
Option B is correct. The @Temporal annotation must be used for java.util.Date/java.util.Calendar only.
(See 9.1.20 of the JPA Specification.)
Option A and E are incorrect. This is a valid use of @Transient and the transient declaration is fine as
well. (See 9.1.16 of the JPA Specification.)
Option C is incorrect. This LOB definition is correct. See 9.1.19 of the JPA Specification.)
Option D is incorrect. This is a valid use of @Basic. The fetch type is eager by default anyway, and the
optional flag is just a hint (defaulting to true also). (See 9.1.18 of the JPA Specification.)
A Book entity must be mapped to a legacy database that uses multiple columns to represent a primary
key for each row. The primary key is composed of two integers. The Book entity has a single persistent
field, bookname.
Which statement about mapping the primary keys is correct?
A The developer can use the @Id annotation on multiple fields to define which fields comprise the
composite key. For example, given a complete definition:
10. @Entity public class Book {
11. @Id int id1;
12. @Id int id2;
13. String bookname;
13. }
B The developer can properly code an external Id class, say MyId, that holds the primary key values. The
entity can then be defined as follows:
@Entity
@IdClass(MyId.class)
public class Book {
String bookname;
}
C The developer can properly code an external Id class, say MyId, annotated with @Embeddable, that
holds the primary key values. The entity can then be defined as follows:
@Entity
public class Book {
String bookname;
@EmbeddedId private MyId id;
D When a primary key class is defined to hold a composite key, it need NOT be public but it must have a
public no-arg constructor and it must be serializable.
Reference
See 2.1.4 and 2.1.5 of the JPA Specification.
Option A is incorrect. The developer can only use @Id for simple (non-composite) keys. Composite keys
cannot be created this way. See 2.1.4 of the JPA Specification. (Unless the developer is using an IdClass,
but in that case the developer must supply an IdClass class as well.)
Option B is incorrect. The developer needs to mark each field that makes up the IdClass with @Id in the
entity. In this case, the entity should have had @Id int id1; @Id int id2; (See 9.1.15 of the JPA
Specification.)
Option C is correct. This is the correct way to use @EmbeddedId.
Option D is incorrect. It must be public, as well having the other attributes (See 2.1.4 of the JPA
Specification.)
Given an excerpt from an entity bean Bar, which references another entity bean Foo:
10. @OneToMany(targetEntity=Foo.class)
11. public Collection<Foo> getFoos() {
12. return foos;
13. }
No descriptor files are used.

Which statement is correct?
A This is a unidirectional relationship.
B This is a bidirectional relationship.
C Replacing line 10 with @OneToMany, removing the targetEntity annotation element, changes the
behavior of this code.
D Additional mapping information is necessary to make this a valid definition.
Reference
Option A is correct, and Option B is NOT correct. It is unidirectional because if it was bidirectional then
the mappedBy attribute must be used in the annotation. (See 9.1.24 of the JPA Specification.) Put
another way, if it was bidirectional, then there must be an owning and an inverse side. In a one-to-many
relationship, the many side must be the owning side. Because this is the "one" side, not the "many" side
(OneToMany), if this was bidirectional, it would have to be the inverse. And an inverse always refers to
the owning with a mappedBy. (See 2.1.7 of the JPA Specification.) Because there is no mappedBy, it is
not bidirectional.
Option C is incorrect. Because this code uses generics on line 11, the annotation element is not even
necessary. (See 9.1.24 of the JPA Specification.)
Option D is incorrect. No additional mapping information is needed. (See 9.1.24 of the JPA
Specification).
A domain model comprises two entities: Flea and Dog. The developer is required to construct these
entities so that the Flea and Dog entities are in a unidirectional many-to-one relationship.
Which statement about implementing this model is NOT correct?
A The @ManyToOne annotation must be placed in the Flea entity.
B If a @JoinColumn annotation is used, it must be placed in the Flea entity.
C The Dog entity must contain the @OneToMany annotation.
D The Flea entity is, by default, mapped to a table containing a foreign key.
Reference
For an example of this scenario, see 2.1.8.3 and 2.1.8.3.2 of the JPA Specification. Option C is the option
that is NOT correct here. Because this is a unidirectional relationship, the OneToMany annotation should
NOT be used. All of the other options are correct. That is, the Dog entity does NOT reference the Flea
entity, the Flea entity is the owner and as such, contains the foreign key.
Which statement is correct about mapping hierarchies?
A The single-table strategy does NOT support queries that range over the hierarchy very well.
B The single-table strategy requires a discriminator column.
C The table-per-concrete class strategy provides good support for polymorphic relationships.
D If a mapped superclass is at the root of an inheritance hierarchy, it has its own table when this
hierarchy is implemented with the joined-subclass strategy where each subclass is mapped to a single
table.
Reference
Option A is incorrect, it does. No joins are necessary. (See 2.1.10.1 of the JPA Specification.)
Option B is correct, it does. (See 2.1.10.1 of the JPA Specification.)
Option C is incorrect. It does not, because it requires expensive SQL UNIONs. (See 2.1.10.2 of the JPA
Specification.)
Option E is incorrect. Mapped superclasses are NOT entities, but a way to share persistent entity state
and mapping information. (See 2.1.9.2 of the JPA Specification.)
Given the definition for a mapped superclass:
5. @MappedSuperclass
6. public abstract class Tome {
7. int papyrus;
8. }
and given the definition for an entity that uses it:
11. @Entity
12. public class Book extends Tome {
13. @Id Integer id;
14. @Column(name="NAMEBOOK")
15. String bookName;
16. }
The associated descriptor file has the following snippet pertaining to this entity:
21. <entity class="Book">
22. <attribute-override name="papyrus">
23. <column name="EBOOK" />
24. </attribute-override>
25. <attributes>
26. <basic name="bookName">
27. <column name="TOMENAME"/>
28. </basic>
29. </attributes>
30. </entity>
No other parts of the deployment descriptor affect this configuration.
A The descriptor and metadata excerpts given above result in an undefined behavior.
B The Book entity is mapped to the BOOK table, with its bookName field mapped to TOMENAME in this
table. The papyrus field is mapped to the column EBOOK in the BOOK table.
C The Book entity is mapped to the BOOK table, with its bookName field mapped to TOMENAME in this
table. The papyrus field is mapped to the column EBOOK in the TOME table.
D The Book entity is mapped to the BOOK table, with its bookName field mapped to NAMEBOOK in this
table. The papyrus field is mapped to the column EBOOK in the BOOK table.
E The Book entity is mapped to the BOOK table, with its bookName field mapped to NAMEBOOK in this
table. The papyrus field is mapped to the column EBOOK in the TOME table.
Reference
Option B is correct. By default, the Book entity is mapped to the Book table. (See 9.1.1 of the JPA
Specification.) A mapped superclass is NOT mapped to a different table, because its state is part of the
BOOK table. So this makes Option C and Option E incorrect. Line 14 maps the bookName field to
NAMEBOOK, but line 26 overwrites this to TOMENAME. (See 10.1.4.10 of the JPA Specification). So
Option D is incorrect. Finally, the attribute-override annotation ensures that the papyrus field is mapped
to EBOOK. (See 10.1.3.13 and 9.1.10 of the JPA Specification). The descriptor and metadata excerpts are
fine - no conflicting undefined behavior results, making Option A incorrect.
Location: > Section 6: Java Persistence Entity Operations > Objective 6.1 > Question 31
Given an excerpt from a stateless session bean that is manipulating entities through the entity manager
assigned to the variable em. The method executes within a REQUIRES_NEW transactional context:
10. public void deWorm(int personId) {
11. Person p = em.find(Person.class, Integer.valueOf(personId));
12. em.remove(b);
13. em.remove(b);
14. }
The Person entity is in a one-to-one relationship with a Car entity. A client calls the method deWorm
with a personId corresponding to an existing Person entity in the database.
Which statement about the behavior of entity removal is correct?
A The entity is removed from the database before line 13 is reached.
B A related Person entity is removed only if the relationship is annotated with cascade=ALL (assuming no
descriptors are used).
C Lines 11 to 13 represent an incorrect use of the find or remove methods on the EntityManager
interface.
D An exception is NOT thrown on line 13
Reference
Option D is correct. No exception is thrown. It is valid to call remove on a removed entity. The semantics
is that the second remove is ignored. (See 3.2.2 of the JPA Specification.)
Option A is incorrect. A developer cannot say it will be removed (from the database, as the question
states) at this point. The specification (3.2.2 of the JPA Specification) says that it will happen "at or
before transaction commit or as a result of the flush operation."
Option B is incorrect. It can be annotated with cascade=REMOVE. (See 3.2.2 of the JPA Specification.)
Option C is incorrect. This is the correct use of the interface.

Entities can be in a new, managed, detached, or removed state.
Which statement is correct about these states?
A Entities in the managed or detached states have a persistent identity, while those in the new and
removed states do NOT.
B If an entity in the managed state is persisted again, the persist operation is ignored, but cascaded to
the appropriate relationships referenced by the entity.
C Persisting an entity in the removed state causes an exception to be thrown.
D Persisting an entity in the detached state moves it to the managed state.
Reference
Option A is incorrect. Those in the removed state have a persistent identity. (See 3.2 of the JPA
Specification.)
Option B is correct. (See 3.2.1 of the JPA Specification.) The cascade still works when the developer
persists a managed entity.
Option C is incorrect. It does NOT cause an exception. It does cause the entity to become managed. (See
3.2.1 of the JPA Specification.)
Option D incorrect. An exception is thrown. (See 3.2.1 of the JPA Specification.)
Assume Book is an entity and em is bound to an entity manager.
Which statement is correct about merging detached entity state?
A All persistent fields of an entity are used in a merge.
B Some time after the following code is executed:
Book flashy= new Book("Flashman");
em.merge(flashy);
the object bound to the variable flashy becomes managed.
C If the developer attempts to merge a detached Book entity with an entity manager that is NOT
currently managing an entity with the same identity, an exception is generated.
D Merging an entity in the removed state results in either an exception or a transaction commit fail.
Reference
Option A is incorrect. Persistence providers actually ignore fields that are marked as LAZY if they have
NOT been fetched. If they have been fetched, they are used. (See 3.2.4.1 of the JPA Specification.)
Option B is incorrect. It will NOT be managed. The object returned by merge is managed (discarded in
this example) as the state (of flashy) is actually copied into a new instance that becomes merged. (See
3.2.4.1 of the JPA Specification.)
Option C is incorrect. You can merge any kind of detached entity, regardless of whether it is currently
managed. (See the first bullet point in 3.2.4.1 of the JPA Specification.)
Option D is correct. The developer cannot merge removed entities. (See 3.2.4.1 of the JPA Specification.)
Given the following entity definition:
10. public class Book extends BookSuperDuper {
12. @Id public Integer id;
13.
14. public void prepersist() {
15. }
16. }
This uses the following class:
20. @MappedSuperclass
21. public abstract class BookSuperDuper {
22. @PrePersist
23. public void prepersist() {
24. System.err.println("--- @PrePersist in BookSuperDuper---");
25. }
26. }
No descriptors or other metadata are used.
Which method is called when an instance of Book is successfully persisted?
A Neither the prepersist method in Book nor the prepersist method in BookSuperDuper is called.
B Only the prepersist method in Book is called.
C Only the prepersist method in BookSuperDuper is called.
D The perpersist method in Book is called, followed by the prepersist method in BookSuperDuper.
E The perpersist method in BookSuperDuper is called, followed by the prepersist method in Book.
Reference
Option C is correct. (See 3.5 of the JPA Specification.) A life-cycle callback method can be defined on a
mapped superclass, as has been done here. According to section 3.5.4 of the JPA Specification, you can
override it as well. Ordinarily, this would NOT cause the overridden method to be invoked, but in the
example case, there is no @PrePersist annotation on line 13. So the overridden method is invoked. See
the footnote in this section.
Options A, B, D, and E are incorrect because Option C is the correct order.
Which statement about versioning is correct?
A Version-locking fields defined in an entity can be only of type int, Integer, short, Short, long, or Long.
B The following is a valid declaration of a version property:
10. @Version
11. @Column(name="oof")
C An entity cannot expose a method that returns the version number to clients of that entity.
D An entity that has a version attribute cannot be in a relationship with an entity that does NOT have a
version attribute (assuming no configuration files are used).
Reference
Option A is incorrect. They can be of type java.sql.Timestamp too. (See 9.1.17 of the JPA Specification.)
Option B is correct. See section 9.1.17 of the JPA Specification for the definition of this annotation.
Option C in incorrect. It is correct to provide (read) access to the version. (See 3.4.2 of the JPA
Specification.)
Option D is incorrect. The developer can mix entities that support and do NOT support optimistic
locking. (See 3.4.2 of the JPA Specification.)
Location: > Section 7: Persistence Units and Persistence Contexts > Objective 7.1 > Question 36
Which statement about JTA and resource-local entity managers is correct?
A The default transaction type for an entity manager is JTA in both Java EE and Java SE environments.
B The developer cannot use a resource-local entity manager in a Java EE environment.
C The EntityTransaction interface must be used when using a resource-local entity manager.
D Application-managed entity managers can be only of JTA transaction type.
Reference
Option A is incorrect. The default is resource-local for Java SE. (See 6.2.1.2 of the JPA Specification.)
Option B is incorrect. The developer can. (See 6.2.1.2 of the JPA Specification for an example.)
Option C is correct. The developer needs to use this to explicitly start/commit the transactions. (See
5.5.2 and 5.5.2.1 of the JPA Specification.)
Option D is incorrect. They can be resource-local as well. (See 5.5 of the JPA Specification.)
Which statement about container-managed persistence contexts is correct?
A A stateless session bean can create and use a container-managed extended persistence context.
B A transaction-scoped container-managed persistence context can be used only in a stateful session

bean.
C The lifetime of an transaction-scoped container-managed persistence context associated with a

session bean lasts only as long as the method using the context.
D When container-managed entity managers are used, the application does NOT interact with the entity
manager factory.
Reference
Option A is incorrect. Only a stateful session bean can. (See 5.6.2 of the JPA Specification.)
Option B is incorrect. It can be used almost anywhere and is not limited to a stateful session bean at all.
The only ones that are limited to a stateful bean are extended contexts. (See 5.6.2 of the JPA
Specification.)
Option C is incorrect. It is transaction-scoped, so it lasts as long as the transaction, NOT any method.
Option D is correct. The developer does NOT retrieve entity managers from a factory in this case; that is
only used for application-managed contexts. (See 5.2 of the JPA Specification.)
Which statement about application-managed persistence contexts is correct?
A Application-managed persistence contexts must always be extended in scope, and cannot be

transaction-scoped.
B A developer can use methods on the EntityManagerFactory API to join or retrieve a transaction.
C Application-managed persistence contexts are supported in Java SE environments only; NOT Java EE
environments.
D Application-managed persistence contexts cannot use a resource-local transactional type.
Reference
Option A is correct. (See 5.7 of the JPA Specification.)
Option B is incorrect. The developer uses methods on the EntityManager API. (See 5.7 of the JPA
Specification for an example.) The EntityManagerFactory only has methods to create, check whether
one is open, and close an entity manager.
Option C is incorrect. They can be used in Java EE environments also. (See 5.1 of the JPA Specification.)
Option D is incorrect. It can be resource-local or JTA. (See 5.5 of the JPA Specification.)
Given an excerpt from a stateful session bean:
09. @Stateful
10. public class MyBean implements MyiMy {
11. @PersistenceUnit(unitName="MyService")
12. EntityManagerFactory emf;
13. EntityManager em;
14. @PostConstruct
15. public void init() {
16. em = emf.createEntityManager();
17. }
18. public void checkoutBook(int bookId) {
19. em.joinTransaction();
20. Book b = em.find(Book.class, bookId);
21. b.setCheckedOut(true);
22. }
23. }
The MyService persistence unit has been configured so that the entity managers provided by the entity
manager factory are JTA entity managers. The Book entity exists. Moreover, checkoutBook and init are
business methods declared in MyiMy.
Which statement is true, assuming no passivation occurs?
A If a JTA transaction is NOT active, line 19 does nothing.
B If a JTA transaction is active, line 19 ensures that the entity manager joins the transaction; but only if
the transaction was created in a bean-managed transactional component.
C The annotation on line 11 and the workings of the init method do NOT reflect how an entity manager
should be created.
D This code work just fine when called from a stateful session bean method with a REQUIRES_NEW
transaction attribute.
Reference
Option A is incorrect. A JTA transaction must be active, otherwise, an exception is thrown. (See 3.1.1 of
the JPA Specification API documentation for this method.)
Option B is incorrect. It does NOT matter how a JTA transaction is created: bean-managed or container-
managed are both fine.
Option C is incorrect. This code is fine. (See 5.7 and 5.7.1.1 of the JPA Specification.)
Option D is correct. As long as a JTA transaction is in place, this code is fine. (See 5.7 and 5.7.1.1 of the
JPA Specification.)
An application, APP, is deployed as an EAR. The library directory of the EAR contains a jar file, foo.jar.
The foo.jar file contains a persistence.xml and plattegrond.xml file located in its META-INF directory and
persistence classes. No other files within the EAR contain persistence classes or a persistence.xml file.
Given an excerpt from the persistence.xml file:
10. <persistence-unit name="MyPU">
11. <mapping-file>META-INF/plattegrond.xml</mapping-file>
12. </persistence-unit>
A No persistence unit is defined at all because this is NOT a valid location for a persistence unit to be
defined.
B The mapping metadata is only ever gathered from persistence.xml only.
C The mapping metadata is only ever gathered from persistence.xml and the persistence classes only.
D The mapping metadata is only ever gathered from persistence.xml and the persistence classes and
plattegrond.xml only.
E The mapping metadata is only ever gathered from persistence.xml, orm.xml if it exists, and the
persistence classes and plattegrond.xml only.
Reference
Option A is incorrect. It is valid to put it in a jar file in the library of an EAR. (See 6.2 of the JPA
Specification.)
Option B is incorrect. plattegrond.xml is also used.
Option C is incorrect. plattegrond.xml is also used.
Option D is incorrect. orm.xml is used as well, if it exists.
Option E is correct. (See 6.2.1.6 and 6.2.1.8 of the JPA Specification.)
Location: > Section 8: Java Persistence Query Language > Objective 8.1 > Question 42
Given an excerpt from an entity:
10. @Entity
11. public class Koala {
12. int children;
13. @Id
14. private Integer id;
15. /* ... */
16. }
The following code was written to find the maximum and average number of children across all Koala
entities:
20. String query = "SELECT max(k.children), AVG(k.children) from Koala k";
21. Query q = em.createQuery(query);
22. Object[] o = (Object []) q.getSingleResult();
Which two statements are correct? (Choose two.)
A There is a syntax error in the JPQL on line 20.
B If the variable o is NOT null, the types of the two values in the array are Integer and Double
respectively.
C There is an error in the typecasting on line 22, which results in a runtime or compile-time exception.
D If the variable o is NOT null, the types of the two values in the array are Double and Double
respectively.
E The syntax of the JPQL statement on line 20 is valid and the code executes without an error.
F A runtime exception is generated on line 22.
Reference
Option E and Option B are correct. This is a valid JPQL query. (See 4.8.4 of the JPA Specification.) The
type of the return value is (Object[]) (See 3.6.1 of the JPA Specification) and in this case the MAX
aggregate function returns Integer and AVG a Double (See 4.8.4 of the JPA Specification.)
Options A, C, D, and F are incorrect because there is no syntax error in the query or the code.
A Leopard entity is in a one-to-many relationship with a Spot entity. Given an excerpt from the Leopard
entity denoting this:
10. @OneToMany(mappedBy="spoton", fetch=FetchType.LAZY)
11. Collection<Spot> spots;
A developer wants to ensure that whenever Leopard entities are retrieved, the associated Spot entities
are also retrieved. The query must return all Leopard instances, regardless of whether they have Spot
instances.
Which query accomplishes this?
A SELECT l FROM Leopard l
B SELECT l FROM Leopard l INNER JOIN FETCH l.spots
C SELECT l FROM Leopard l OUTER JOIN FETCH l.spots
D SELECT l,s FROM Leopard l LEFT JOIN FETCH l.spots s
E SELECT l FROM Leopard l LEFT OUTER JOIN FETCH l.spots
Reference
Option E is correct. (See 4.4.5.3 of the JPA Specification.)
Option A is incorrect because the fetch type is lazy
Option B is incorrect because it does an inner instead of an outer join and the question asks for
"regardless of whether Spot instances are there."
Option C is incorrect because the syntax is wrong. The developer cannot have "OUTER JOIN FETCH" only
"LEFT JOIN FETCH" or "LEFT OUTER JOIN FETCH."
Option D is incorrect because you are NOT allowed to name the fetch ("s" is not allowed).
A domain model for a corporation includes a User entity that is in a one-to-many bidirectional
relationship with a Pen entity. In other words, User.pens is the collection of pens for a User, while
Pen.owner is the User entity owning that Pen. A developer wants to select only User entities that have
at least one associated Pen entity. The developer writes the following query, which does the job:
SELECT u from User u WHERE EXISTS (SELECT b from u.books b)
Which query returns the same set of results when there are Book and Pen entities in the database?
A SELECT u from User u WHERE COUNT(u.books) > 0
B SELECT u from User u WHERE EXISTS (SELECT b from Book b where b.owner = u)
C SELECT u from User u WHERE ANY(u.books)
D SELECT u from User u WHERE NOT SOME(u.books)
Reference
Option A is incorrect. COUNT cannot be used like this, but SIZE can. (See 4.6.16.2 of the JPA
Specification.)
Option B is correct. EXISTS takes a subquery, and the one given here is valid. (See 4.6.13 of the JPA
Specification.)
Option C is incorrect. ANY must be used with a comparison operator, such as <, = an do on. See 4.6.14 of
the JPA Specification and the BNF for comparison_expression in section 4.14 of the JPA Specification.
Option D is incorrect. SOME must be used with a predict, such as <, = and so on. (See 4.6.14 of the JPA
Specification.)
A Leopard entity is in a one-to-many bidirectional relationship with a Spot entity. Given an excerpt from
the Leopard entity denoting this:
10. @OneToMany(mappedBy="spoton", fetch=FetchType.LAZY)
11. Collection<Spot> spots;
The following code is found in a stateful session bean, intended to delete those leopards who do not
have spots:
18. @TransactionAttribute(TransactionAttributeType.REQUIRED)
19. public void removeSpotlessLeopards() {
20. em.persist(new Leopard("meow"));
21. em.createQuery("DELETE FROM Leopard l " +
22. "WHERE l.spots IS EMPTY ").executeUpdate();
23. em.createQuery("SELECT l FROM Leopard l ").getResultList();

24. }
A It is NOT necessary to execute this code within a transaction.
B The syntax of the DELETE FROM JPQL statement is invalid.
C The query on line 23 is guaranteed to return an empty list.
D This type of code is recommended against in the JPA Specification.
Reference
Option D is the correct answer. (See 4.10 of the JPA Specification and in particular, see the caution.)
Option A is incorrect. The JPA Specification demands that this be executed in a transaction, or else a
TransactionRequiredException is thrown. (See 3.6.1 of the JPA Specification.)
Option B is incorrect. The syntax is correct. (See 4.10 of the JPA Specification.)
Option C is incorrect. There is no guarantee. Line 22 executes against the database, bypassing the
persistence context. As a result, the developer might find the instance in line 20 still available in line 23.
An Order entity (in the package foo) has an id and name field. Given an entity manager em, which
statement can successfully create a Query object?
A em.createSQLQuery("SELECT id, name FROM Order", Object)
B em.createQuery("SELECT o FROM Order o")
C em.createNamedQuery("SELECT o FROM Order o")
D em.createQuery("SELECT o FROM Order o", foo.Order.class)
Reference
See section 3.1.1 of the JPA specification.
Option A is incorrect because native queries are created with createNativeQuery
Option B is correct.
Option C is incorrect because the developer should supply the name of the query, NOT a query itself.
Option D is incorrect because it is mixing the syntax for creating native queries (adding a class as second
parameter erroneously) and dynamic queries (the syntax of the first parameter is valid Java Persistence
API query language).
Given an excerpt from a Book entity:
10. @Entity
11. public class Book {
12. @Id private Integer id;
13. public String bookName;
14. @Enumerated( EnumType.ORDINAL )
15. public Status status;
16. @Temporal(TemporalType.TIMESTAMP)
17. public java.util.Date loanDate;
18. public enum Status {IN, OUT};
19. /* ... */
20. }
A developer constructs the following Query instance:
40. Query q = em.createQuery("select b from Book b where " +
41. "b.bookName=:n and b.loanDate=:d and b.status=:s").
42. setParameter("d",new Java.util.Date()).
43. setMaxResults(2).
44. setParameter("n", "A").
45. setParameter("s", 0).
46. setFirstResult(0);
Which line causes a runtime exception to be generated?
A Line 41
B Line 42
C Line 43
D Line 44
E Line 45
F Line 17
Reference
Option E is correct. The status field of Book is an enum. Even though the annotation on line 15 maps it
to an ordinal in the database, its type is still an enum in the query. So passing 0 instead of Status.IN for
example, is a type error and results in an exception.
Options A, B, C, and D are incorrect because the rest of the calls on the Query API are correct. (See 3.6 of
the JPA Specification.)
Option F is incorrect because there is nothing wrong with using java.util.Date as long as the developer
uses the @Temporal annotation. (See 9.1.20 of the JPA Specification.)
Location: > Section 9: Transactions > Objective 9.1 > Question 48
Which statement about transaction demarcation is correct?
A A session bean can be designed with bean-managed and container-managed transaction

demarcation, at the same time.
B A message-driven bean can be designed with bean-managed and container-managed transaction

demarcation, at the same time.
C Entities can be designed with bean-managed or container-managed transaction demarcation, but not
with both at the same time.
D Both stateless and stateful session beans can designed with bean-managed transactions. .
E Only stateless session beans can be designed with bean-managed transactions.
References
Option D is correct. (See 13.3.1 of the Core Specification.)
Options A and B are incorrect because the developer cannot use both bean-managed and container-
managed transaction demarcation at the same time.
Option C is incorrect because Option D is correct - The developer cannot specify the management type.
Option E is incorrect. The developer can have bean-managed transactions with stateful beans. (See
13.3.1 of the Core Specification.)
A client makes a request to the yummy method of a stateless session bean, shown below:
10. @Stateless
11. @TransactionManagement(javax.ejb.TransactionManagementType.BEAN)
12. public class SoupBean implements Soup {
13. @Resource javax.transaction.UserTransaction ut;
14. @EJB Carrot carrot;
15. public void yummy() {

16. ut.begin();
17. carrot.peel();
18. ut.commit();
19. }
20. }
The Carrot bean is a stateless session bean using container-managed transactions. It has the following
definition for the peel business method:
30. @TransactionAttribute(REQUIRED)
31. public void peel() {
32. }
No descriptor files are used.
Which statement about the transaction behavior is correct?
A If the client is associated with a transaction, the server throws an exception on line 16.
B If the client is associated with a transaction, it is suspended before the yummy method is invoked. An
exception is thrown when this method invokes the peel business method.
C If the client is associated with a transaction, it is suspended before the yummy method is invoked. The
yummy method starts a new transaction, which is suspended before the peel method is invoked, and
resumed after the peel method exits. After the yummy method exits, the client's transaction is resumed.
D If the client is associated with a transaction, it is suspended before the yummy method is invoked. The
method call to peel does not suspend or resume transactions. After the yummy method exits, the
client's transaction is resumed.
Reference
Option D is correct. If a client in a transaction makes a call to a method in a bean-managed transaction

instance, the client's transaction is suspended until that call exits. See Table 12 and the explanations in
section 13.6.1 of the Core Specification. At line 17, a transactional context has been created, so no new
context must be created to invoke peel.
Options A, B, and C are incorrect because they do not follow these rules. For example, no exceptions are
thrown because it is quite legitimate to call a bean-managed bean from a client in a transactional
context (see 13.6.1 of the Core Specification), so Options A and B are incorrect.
Given a code excerpt from a session bean:
10. @Stateful
11. @TransactionManagement(BEAN)
12. public class LookingForTroubleBean implements LookingForTrouble {
13. @Resource javax.Transaction.UserTransaction ut;
14. @Resource DataSource ds1;
15. @Resource DataSource ds2;
16. Connection con;
17.
18. public void zubb() {
19. Statement stmt;
20. ut.begin();
21. con = ds1.getConnection();
22. stmt = con1.createStatement();
23. stmt.executeUpdate("INSERT INTO CULPRITS VALUES (1)");
24. con.close();
25. }
26. @Remove
27. public void buzz() {
28. Statement stmt;
29. con = ds2.getConnection();
30. stmt = con2.createStatement();
31. stmt.executeUpdate("INSERT INTO CULPRITS VALUES (2)");
32. con.close();
33. ut.commit();
34. }
35.}
Assume that the tables and JTA datasources are setup correctly, and that the update statements are
valid and do NOT cause an exception. A remote client, which is NOT executing in a transactional context,
locates an instance of this session bean and calls method zubb, and then the method buzz.
A An exception is thrown when the method zubb ends.
B An exception is thrown when the method buzz ends.
C No exceptions are thrown. This is valid code.
D An exception is thrown on line 29.
E An exception is thrown on line 33.
Reference
Option C is correct. A stateful session bean can retain a transaction across client calls. (See 13.3.3 of the
Options A, B, and D are incorrect because the code is correct. No exceptions occur because of the
transactional setup. See Option C.
Given two excerpts from the implementation of a session bean MySessionBean:
10. @TransactionAttribute(REQUIRES_NEW)
11. public class MySuper {
12. public void foo() {}
13. public void bar() {}
14. }
30. @Stateless
31. @TransactionAttribute(NOT_SUPPORTED)
32. public class MyBean extends MySuper implements MyI {
33. public void foo() {}
34. @TransactionAttribute(SUPPORTS)
35. public void bar() {}
36. }
A deployment descriptor contains the following information pertaining to the transaction settings:
10. <container-transaction>
11. <method>
12. <ejb-name>MySessionBean</ejb-name>
13. <method-name>foo</method-name>
14. </method>
15. <trans-attribute>Mandatory</trans-attribute>
16.</container-transaction>
foo and bar are business methods defined in interface MyI.
Which statement correctly defines the transaction attributes assigned to the methods foo and bar
respectively?
A REQUIRES_NEW, SUPPORTS
B REQUIRES_NEW, REQUIRES_NEW
C MANDATORY, REQUIRES_NEW
D MANDATORY, SUPPORTS
E NOT_SUPPORTED, SUPPORTS
F NOT_SUPPORTED, REQUIRES_NEW
Reference
Option D is correct. foo is set to REQUIRES_NEW in the superclass. It is overridden to NOT_SUPPORTED

in the session bean, and later overridden again to MANDATORY when the descriptor bar's transaction
attribute is set to SUPPORTS in the session bean.
Options A, B, E, F, and C are incorrect because the correct order is described in Option D.
Given an excerpt from a stateful session bean:
10. @Stateful
11. public class MyStatefulBean implements MyStateful, SessionSynchronization {
13. public void afterCompletion(boolean f) {}
14. public void beforeCompletion() { ctx.setRollbackOnly(); }
15. public void afterBegin() {}
16. public void inc() {}
17. }
The MyStateful interface is a local business interface that declares inc to be a business method. No
deployment descriptor is used. A stateless session bean using container-managed transactions has a
business method that acts as a client:
20. @TransactionAttribute(TransactionAttributeType.REQUIRED)
21. public String doIt() {
22. ms.inc();
23. }
The method doIt is called without a transactional context.
Which statement properly reflects the order of method invocation?
A doIt, beforeCompletion, afterBegin, inc, afterCompletion
B doIt, inc, beforeCompletion, afterBegin, afterCompletion
C doIt, inc, afterBegin, beforeCompletion, afterCompletion
D doIt, afterBegin, inc, beforeCompletion, afterCompletion
E doIt, inc, afterBegin, beforeCompletion
Reference
Option D is correct. doIt is called first, as indicated in the question. Because you are now in a
transactional context, the container then invokes afterBegin before it invokes the business method. (See
13.6.2.11 of the Core Specification). After, the business methods, beforeCompletion and
afterCompletion are called. (See 4.3.7 of the Core Specification). The code in beforeCompletion causes
an exception to eventually be generated, but afterCompletion is still called (with false).
Options A, B, C, and E do not agree with this order and so are incorrect.
Location: > Section 10: Exceptions > Objective 10.1 > Question 53
Which statement is true about session beans and exceptions?
A The methods of the business interface can declare any application exceptions.
B Business methods can throw any type of exception.
C Business method interceptors cannot throw exceptions.
D All exceptions that can be thrown in a business method must be caught and wrapped in an
EJBException.
Reference
Option A is correct. (See 3.3 of the Simplified Specification.)
Option B is incorrect. It cannot throw java.rmi.RemoteException. See 3.3 of the Simplified Specification.)
This does not contradict Option A.
Option C is incorrect. They can. (See 3.4 of the Simplified Specification.)
Option D is incorrect. There is no requirement for this in the specification.
Given the complete code defining an exception that is declared and thrown within the business method
of a stateful session bean:
10. public class OhException extends RuntimeException {
11. }
The business method runs in a transactional context.
Which statement about the exception behavior is correct?
A The business method cannot throw instances of OhException.
B This exception is an application exception.
C This exception rolls back the transaction.
D This exception must be declared in the throws clause of the method.
Reference
Option A is incorrect. There is no restriction on this kind of exception. Just RemoteException. (See 3.3 of
the Simplified Specification.)
Option B is incorrect. It has NOT got an ApplicationException annotation. (See 14.2.1 of the Core
Specification.)
Option C is correct. It is a system exception. (See 14.2.2 of the Core Specification.)
Option D is incorrect, it need NOT. It is a runtime exception.

Which EJB role is responsible for taking actions to correct problems that cause non-application
exceptions?
A Enterprise Bean Provider
B System Administrator
C EJB Container Provider
D EJB Server Provider
Reference
See 14.5 of the Core Specification.
Option B is correct because this is the role of the system administrator.
Options A, C, and D are incorrect because A is correct.
A stateless session bean contains the following business method:
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public String getVal() throws EJBException, Exception {
throw new java.lang.Exception("Surprise!");
What is the result if a client calls this bean?
A It receives a null value. No exception is received by the client.
B The client receives an exception that is an instance of java.lang.Exception (NOT a subclass of this type).
C The client receives an exception that is an instance of javax.ejb.EJBException (NOT a subclass of this
type).
D The client receives an exception that is an instance of java.rmi.RemoteException (NOT a subclass of

this type).
Reference
Option B is correct because this is an application exception and these passed "precisely" to the client so
it gets the same exception. (See 14.1.2 of the Core Specification.)
Options A, C, and D are all incorrect because B is the correct answer. All the others are not instances of
java.lang.Exception but instead are subclasses.
A business method in a stateful session bean accesses the EJBContext.getRollbackOnly method.
When will a call to the getRollbackOnly method throw an exception?
A If the business method executes with a REQUIRED transaction attribute.
B If the business method executes with a REQUIRES_NEW transaction attribute.
C If the business method executes with a SUPPORTS transaction attribute.
D If the business method executes with a MANDATORY transaction attribute.
Reference
Option C is correct. (See 13.6.2.9 of the Core Specification.) It is handled for the other three transaction
attributes in Options A, B, and D and so it does NOT throw an exception for these attributes.
Location: > Section 11: Security Management > Objective 11.1 > Question 58
Given an excerpt from a stateless session bean:
10. @Stateless
11. @RolesAllowed("BOND")
12. public class YourBean implements MyI {
13. /* ... */
14. }
The bean also has a deployment descriptor, and given an excerpt:
20. <assembly-descriptor>
21. <security-role>
22. <role-name>JAMES</role-name>
23. </security-role>
24. </assembly-descriptor>
Which roles must be mapped to security principals and groups to secure this session bean?
A BOND
B JAMES
C JAMES and BOND
D No roles
Reference
Option C is correct because RolesAllowed and the role-name declare roles that should be mapped. See
17.3.1 of the Core Specification where it mentions that the security-role augments the aggregation of
other roles defined in the descriptors.
Options A, B, and D are incorrect because C is correct. Both roles must be mapped.
Given a snippet from a stateful session bean:
10. @Resource DataSource myDS;
11.
12. public void doSomeWork() {
13. Connection con = myDS.getConnection();
14. }
Assume that this bean must be deployed into an established application server that has security
principals already configured.
Which EJB role is responsible for making sure that if this code is left unchanged, the call on line 13 does
NOT fail with a security exception?
A Bean Provider
B Application Assembler
C Deployer
D System Administrator
Reference
Option C is correct. Because this code does NOT perform manual authentication from the resource
manager when it retrieves the connection, it is up to the Deployer to configure this correctly. (See 16.7.2
and 16.7.1.2 of the Core Specification for an example.)
Option A is incorrect. In this case you have asked that the code be left unchanged. When deployed, it is
the Deployer who is responsible for the security role assignment, not the Bean Provider. Bean Providers
and Application Assemblers can supply security roles, but even these are not sufficient. The Deployer
must tie these roles with real security information. (See 17.1 of the Core Specification.)
Option B is incorrect for the same reason as A is incorrect.
Option D is incorrect because it is NOT the role of a system administrator to ensure that code has its
security profile properly configured. The question states explicitly that the security principals have been
configured, so it is a matter of mapping the roles to these principals, and that is the role of the Deployer.
Given an excerpt from a stateless session bean that has a business method barbar:
9. // ...
10. @Stateless public class FooBean implements IFace {
12. // ..
13. public void barbar() {
14. // ...
15. String name = ctx.getCallerPrincipal().getName();
16. // ...
17. }
18. }
19. }
There is no associated deployment descriptor.
Which statement is correct about this code?
A A @RolesAllowed or @DeclareRoles annotation is needed at line 9 to make this execute without

runtime exception.
B Line 15 can sometimes throw a null pointer exception.
C This code execute without a problem.
D No matter what annotations are added, this code raises a java.lang.IllegalState exception.
Reference
Option A is incorrect. This has nothing to do with getCallerPrincipal operation. (See 17.2.5.1 of the Core
Specification.)
Option B is incorrect. The only way for that to happen would be if the context were null (but it is injected
so it will NOT be) or if the getCallerPrincipal returned null, which it is NOT allowed to do. (See 17.6.5 of
the Core Specification.)
Option C is correct. This is legitimate code. (See 17.2.5.1 of the Core Specification.)
Option D is incorrect. It is legal to make a call to getCallerPrincipal in a business method of a stateless

bean. (See 4.5.2 of the Core Specification.)
Given a snippet from a descriptor defining some security properties in two session beans:
10. <session>
11. <ejb-name>BeanB</ejb-name>
12. ...
13. <security-identity>
14. <run-as>
15. <role-name>hyde</role-name>
16. </run-as>
17. </security-identity>
18. ...
19. </session>
20. ...
21. <session>
22. <ejb-name>BeanC</ejb-name>
23. ...
24. <security-identity>
25. <run-as>
26. <role-name>jekyl</role-name>
27. </run-as>
28. </security-identity>
29. ...
30. </session>
A business method in BeanA (not shown here) makes a call to a business method in BeanB, which in turn
makes a call to a business method in BeanC. No other method or class security annotations or metadata
is used. Furthermore, the call into BeanA is made by an authenticated user in the security role hyde.
AThe beans do NOT deploy unless a security identity is specified for Bean A as well.
B The call from BeanA to BeanB fails with a security exception.
C The call from BeanB to BeanC fails with a security exception.
D The business methods in BeanC runs under the security role hyde.
Reference
Option A is incorrect. The developer does NOT need to specify one, it defaults to caller identity. See
17.3.4 of the Core Specification.)
Options B and C are incorrect. There is nothing to indicate an exception is raised.
Option D is correct. It does this by hyde not jekyl. (See 17.3.4.1 of the Core Specification.)

SCBCD-5 Q&amp;A With Explanations - 1

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SCBCD-5 Q&amp;A With Explanations - 1

Diunggah oleh

Hak Cipta:

Format Tersedia

QUESTIONS FOR SCBCD 5.

Which two APIs can be used to implement an EJB? (Choose two.)

A EJB 2.1 APIs

B EJB 3.0 APIs

C HTTP Servlet APIs

D File I/O APIs

E APIs for thread management

Options A and B are correct. (See 2.2 of the Simplifies Specification.)

What programming restrictions are defined in the EJB specification?

B A session bean must implement the javax.ejb.SessionBean interface.

C An enterprise bean must NOT declare any static fields.

D An entity bean class must be NOT be defined as public.

Option A is correct. (See 21.1.2 of the Core Specification.)

A Enterprise Bean Provider

D EJB Server Provider

Option D is incorrect because this refers to (typically) an OS vendor or middleware vendor.

Option A is incorrect because B is correct.

A Deployment descriptor metadata can only be used to modify annotation metadata.

B A deployment exception is thrown if deployment descriptor metadata and annotation metadata

C Metadata annotations can be used as an alternative to deployment descriptors in most cases.

D Annotation metadata can only be used to modify deployment descriptor metadata.

D Entities support the PostConstruct and PreDestroy callbacks.

Option A is correct. See Simplified 5.1.4.

Option B is incorrect because message-driven beans only support PostConstruct/PreDestroy (See

Option C is correct. See Simplified 4.1.4.

Option D is incorrect. See Persistence 3.5.1.

Option E is incorrect. See 4.1.4.

Given the following session bean:

12. public class MyBean ... {

16. public void someMethod() {

Which interceptor classes are called when someMethod() executes?

A No interceptor classes are called.

D MyOtherInterceptor and MyInterceptor.

10. @Stateless public class CrumbleBean implements Crumblee {

11. @Resource int dough;

Options A,C,D are incorrect because B is correct, per the specification.

Given the following excerpt from a stateless session bean:

11. public class OvenBean implement Oven {

12. @Resource SessionContext ejbContext;

15. public void ping(javax.ejb.Timer timer) {

19. // .. more methods here ..

Assume that a timer is set up and initiated for this bean.

B The method ping is called only once.

C The method ping is called at least twice.

D An exception is thrown because of the transactional attribute set on the method

Given the following session bean:

11. public class OvenBean implements Oven {

12. @Resource SessionContext ctx;

13. public void heat() {

14. TimerService t = (TimerService) ctx.lookup("java:comp/TimerService");

15. Collection c = t.getTimers();

16. Timer tee = t.createTimer(1000, null);

19. void foo(Timer t) {

22. // more methods here

B An exception is raised on line 14.

E An exception is raised on line 15.

Option D is correct. See 9.1 of the Simplified Specification.

Location: > Objective 3.1 > Question 13

Which statement characterizes stateless session beans?

A They allow the PostActivate, PostConstruct and PreDestroy life-cycle callbacks

B They require home interfaces.

C Stateless session beans typically execute on behalf a single client.

D They are asynchronous message consumers.

SCBCD-5 Q&A With Explanations - 1

SCBCD-5 Q&A With Explanations - 1