Beruflich Dokumente
Kultur Dokumente
0 FORM 2
Location: > Section 1: EJB 3.0 Overview > Objective 1.1 > Question 1
Which statement correctly identifies the architectural goals of the designers of the EJB architecture?
A The EJB architecture supports the development, deployment, and use of web services.
B The EJB architecture only supports interoperability with programs written in the Java language.
C The EJB architecture addresses the development and deployment of EJB components, but the runtime
aspect is left completely to the discretion of the container providers.
D The EJB architecture requires that users be aware of the low-level connection pooling aspects and
multi-threading characteristics of the Java EE platform.
Reference
Option A is correct. (See section 2.1 "Overall Goals" in the Core Specification.) Option B, C, and D are
incorrect because they are NOT listed as goals in section 2.1
Location: ... > Section 1: EJB 3.0 Overview > Objective 1.2 > Question 2
When a programmer is creating an EJB container, which two APIs should be available or be provided by
the EJB Container Provider or the EJB Server Provider? (Choose two.)
B Common Annotations
Reference
Options A and B are correct. (See the Simplified Specification 2.2. and the Core Specification 21.1.1.)
Location: ... > Section 1: EJB 3.0 Overview > Objective 1.3 > Question 3
B A session bean class must NOT have any superclasses and/or superinterfaces.
Option B is incorrect because it may well have them. (See section 4.6.2)
Option C is incorrect. It must NOT attempt to read (or write) a file descriptor. (See 21.1.2 of the Core
Specification.)
Location: ... > Section 1: EJB 3.0 Overview > Objective 1.4 > Question 4
Which two roles defined by the EJB architecture typically modify the metadata associated with an ejb-jar
in the creation, integration, and deployment of the ejb-jar as part of a larger application? (Choose two.)
A Application Assembler
B System Administrator
D Persistence Provider
Reference
Options A and C are correct. (See the Core Specification, section 2.2.) The assembler is responsible for
combining enterprise beans and the provider for creating the bean. Both would typically manipulate the
metadata.
Option B is incorrect because this role refers to someone who configures the enterprises computing and
network infrastructure.
Option D is incorrect because this role refers to the provider of the persistence runtime.
Option E is incorrect because this role refers to the provider of the EJB container.
Location: ... > Section 1: EJB 3.0 Overview > Objective 1.5 > Question 5
An enterprise bean packaged in an ejb-jar returns instances of a Television class as a result for one of its
business methods. The developer has been asked to create an associated ejb-client JAR file.
D The DTDs and schemas of all XML messages used by the client
Reference
Option B is correct. (See section 20.4 and 20.3 of the Core Specification.)
Option A is incorrect. The developer typically places the ejb-client in the ejb-jar, NOT vice-versa.
Option C is incorrect. Stubs are generated and should NOT be packaged by a developer.
Location: ... > Section 1: EJB 3.0 Overview > Objective 1.6 > Question 6
An enterprise bean has a set of interceptor classes defined for it in two ways: First, the interceptor
classes were specified in the deployment descriptor for the enterprise bean. Second, the classes were
specified using the @Interceptor annotation on the enterprise bean itself.
Which statement describes the runtime and deployment-time use of these metadata?
Reference
Option B is correct. (See the Simplified Specification 2.1 or the Core Specification 12.1.) Because B is
correct, A, C, and D are necessarily incorrect.
Location: ... > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.1 > Question 7
B Life-cycle callback methods can have public, private, protected, or package-level access.
C A life-cycle callback method can only have a single callback annotation. In other words, you cannot
define a single method and give it two different callback annotations.
Reference
Option B is correct.
A non-transient String field in an interceptor associated with a stateful session bean is set to "Hello"
when the stateful session bean is passivated.
What will the state of the field be after the bean is again activated?
C It is set to "Hello".
D The bean will be associated with an arbitrary interceptor instance after activation, and so can have
whatever value the field is set to in that interceptor instance.
Reference
Option C is correct. (See section 4.2.1 of the Core Specification.) The state of the interceptor is
effectively bound to the state of the stateful session bean, that is both states will be preserved across
passivation/activation.
Option D is incorrect because the interceptor state is bound to the state of the session bean in question,
NOT some other arbitrary one.
Location: ... > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.3 > Question 9
As a developer of an enterprise bean you want to ensure that the value of an entry from a bean's
environment is injected into the bean. The entry's name is myDS and the entry's type is
javax.sql.DataSource. Assume that the bean's deployment descriptor correctly defines the entry.
Which two code snippets ensure that this environment resource is successfully injected? (Choose two.)
Options C and D are correct. (See Core Specification 16.2.2.) There is no problem if the field is public,
private, and so on.
Option A is incorrect because you should put the @Resource annotation on the setter, NOT the getter.
(Simplified Specification. 8.1.2)
Option B is incorrect because the name of the variable does not coincide with name of the entry.
Option E is incorrect. The developer does NOT use the @EJB annotation to do this, but the @Resource
one.
Location: ... > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.4 > Question 10
The EJB Timer service can be used to ensure that the EJB container invokes a timeout method on a bean
at a specified time or after a specified period.
Which two types of beans support this Timer service? (Choose two.)
Reference
Option A and Option C are correct. (See Core Specification 18.2.) Message -driven beans are supported
too.
Option D and B are incorrect because these beans are not supported.
Location: ... > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.5 > Question 11
Consider the following excerpt from a session bean with one business method, roast:
10. @Stateful
14. //
15. }
21.
22. }
23. @PostConstruct
25. }
99. }
Assume that the associated descriptor has a dependency of type Temp and name temperature.
What order of invocation occurs if a client creates such a bean and invokes the roast method?
A roast will be called, followed by the container injecting ctx and calling setTemperature, followed by
potatoes being called.
B ctx will be injected and setTemperature called. roast will then be called. potatoes will NOT be called at
all.
C ctx will be injected. This will be followed by a call to potatoes, and finally to roast. setTemperature will
NOT be called.
D ctx will be injected and setTemperature called. potatoes will then be called, followed by roast.
Reference
Option D is correct. According to the Simplified Specification 8.1.1, 9.3.1 and the Core Specification (for
example, 4.3.10), after a new instance is created the SessionContext (if applicable) and other resources
are injected. According to 4.1.4, the PostConstruct life-cycle callback is invoked after any dependency is
injected and before any business method is invoked. So this reflects the correct order of invocation.
Options A, B, and C contradict this order, and so are necessarily incorrect. The PostConstruct method is
valid and is called, as is the setter-type resource injection.
Location: ... > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.6 > Question 12
Which statement about EJB 2.x and EJB 3.0 API interoperability is correct?
A A stateless session bean written to the EJB 3.0 API can be adapted to an EJB 2.1 client interface.
B The developer cannot mix APIs. For example, the developer cannot write an EJB 3.0 session bean while
also implementing an EJB 2.1 EJBHome interface.
C The EJB 2.1 API requires the use of a stateful session bean's home interface to obtain a reference to
the bean's component interface. The developer cannot use dependency injection to obtain a reference
to such a home interface in an EJB 3.0 client of such a bean.
D An adapter class has to be used when accessing EJB 2.0 environment variables of a stateless session
bean, when such a bean is deployed in an EJB 3.0 container.
Reference
Option B is incorrect. The developer can do this. (See 9.4 in the Simplified Specification.)
Option C is incorrect. The developer can use dependency injection on old-style EJB 2.1 home interfaces.
(See 3.6.1 of the Core Specification.)
C When a client looks up a stateful session bean in the JNDI, the same bean is returned every time.
Reference
Option B is incorrect. Session beans do not require home interfaces (See the Simplified Specification
3.5.) Option C is incorrect. (See 4.4 of the Core Specification.) A different bean is returned every time.
Option D is incorrect. Message-driven beans are asynchronous message consumers. (See 2.4.2 of the
Core Specification.)
A Stateless and stateful session beans can implement the javax.ejb.SessionSynchronization interface to
receive transaction synchronization notifications.
B The remote business interface of an EJB 3.0 session bean can be specified using the @RemoteHome
annotation.
C The same business interface cannot be both a local and a remote business interface of a bean.
D A bean class cannot have more than one remote business interface.
Reference
Option A is incorrect. Stateless beans must NOT implement the interface. (See 4.5 of the Core
Specification.)
Option B is incorrect. @RemoteHome is used to specify a home interface for EJB 2.1 client views. (See
10.3 of the Simplified Specification.)
Given an interface:
7. int getBarPackage();
8. }
Here is an excerpt from a stateless session bean that implements this interface:
10. @Stateless
50. }
What methods are exposed to local clients of this stateless session bean?
B getVal
C getBar
Reference
Option D is correct. Both methods are exposed. It also does not matter that there is no @Local on the
interface. (See 10.2 of the Simplified Specification.)
Option A, B, and C are incorrect because this is a valid session bean exposing two methods.
Location: ... > Objective 3.4 > Question 16
A programmer constructs a stateful session bean that contains, in addition to the business methods, the
following three life-cycle callback methods:
@PostConstruct
// add a new unique record into a database, and keep primary key
@PreDestroy
// retrieve the primary key from the local state of this stateful session
@Remove
The initConnection method simply adds a new record to a database table and stores its primary key in
the local state of the stateful session bean. If, for example, the bean can be passivated and reactivated,
and later when the bean is removed and the PreDestroy life-cycle method called, the record can be
removed.
Reference
Option A is incorrect because the PreDestroy should be called here, resulting in the database record
being deleted. Option B is incorrect because the PreDestroy method should be called here, resulting in
the database record being deleted. Option C is correct. See 4.4.3 of the Core Specification for when the
PreDestroy method is NOT called. When passivated, PreDestroy is NOT called. Option D is incorrect
because calling the Remove should ensure that the PreDestroy life-cycle callback method is invoked.
Location: ... > Objective 3.5 > Question 17
The deployment descriptor for the Foo session bean looks similar to this:
10. <enterprise-beans>
11. <session>
12. ...
13. <ejb-name>Foo</ejb-name>
14. <ejb-class>ms.FooBean</ejb-class>
15. ...
16. <resource-ref>
17. <res-ref-name>jdbc/BarDB</res-ref-name>
18. <res-type>javax.sql.DataSource</res-type>
19. <res-auth>Container</res-auth>
20. <res-sharing-scope>Shareable</res-sharing-scope>
21. </resource-ref>
22. ...
23. </session>
24.</enterprise-beans>
Assume that a deployer binds this to an actual resource. The implementation of Foo contains a
reference to a Context object bound to the variable initCtx and a reference to a SessionContext object
bound to the variable ctx.
B (DataSource) ctx.lookup("java:comp:env/jdbc/BarDB");
C initCtx.lookup("java:comp/env/jdbc/BarDB");
D @Resource(name=?jdbc/BarDB?, type=javax.sql.DataSource)
Reference
Options C is a correct way to retrieve a resource manager. (See 16.7.1.2/3 of the Core Specification for
an example.) Option A fails because the datasource name does not correspond with the name on line
17. Option B uses the incorrect path to the resource. It should be jdbc/BarDB. Option D does nothing. It
simply declares a reference to a resource, performing much the same task as the descriptor snippet
given above. (See 16.7.1.3 and 16.7.1.2 of the Core Specification.)
Location: ... > Objective 3.6 > Question 18
A Stateful and stateless session beans can be designated as web service endpoints (can expose a web
services client view).
B A bean that implements a web service endpoint using the JAX-RPC contracts can use a method on the
SessionContext to access the SOAP message for the end point.
D Session beans that provide a web services client view cannot make use of JAX-RPC message handlers.
Reference
Option C is incorrect. They can. They can even see the MessageContext. (See 4.3.6 of the Core
Specification.)
Option D is incorrect. They can. (See 4.6.1. of the Core Specification.) Interestingly, the handlers and
interceptors can share information!
A client tests two stateless session bean business interface references for identity using the equals
method as follows:
A The developer should NOT compare business interface references with the equals method.
C The test on line 12 always succeeds with true, but the test on line 13 always fails with false.
Reference Option A is incorrect. The code is valid. (See 3.4.5.2 of the Core Specification.)
Option D is correct. All business object references of the same interface type for the same stateless
session bean have the same object identity. (See 3.4.5.2 of the Core Specification.)
Location: ... > Objective 4.1 > Question 20
Which method can be successfully invoked on this interface from a message-driven bean?
A getEJBHome
B getCallerPrincipal
C isCallerInRole
D getEJBLocalHome
Reference
Option A, C, and D should NOT be called. (See 5.4.4 of the Core Specification.)
A A message-driven bean can register with the EJB Timer Service for timeout callback notifications.
Option C is incorrect. It also supports PreDestroy. (See 5.4.5 of the Core Specification.)
A developer is given a JMS message-driven bean, which has no descriptors or metadata that describe
acknowledge modes or subscription durability. In addition, the message-driven bean uses bean-
managed transactions and is subscribed to a topic.
What two message-driven bean behaviors can the developer expect to see? (Choose two.)
C Messages will NOT be missed, even if the EJB server is NOT running.
Option D is correct. (See 5.4.16 of the Core Specification.) So the default is non-durable subscription and
automatic acknowledgment.
Option E is incorrect. The developer certainly can specify a durability for a topic. (See 5.14.16 of the Core
Specification.)
@MessageDriven
ctx.setRollbackOnly();
A JMS server receives a message and delivers it to this queue. After executing the onMessage method,
no exceptions are thrown.
C The JMS server sends the same message more than once.
D The LetterBean instance that receives the message immediately moves into the "does NOT exist"
state.
Reference
Option A is incorrect because no exceptions are thrown when setRollbackOnly is invoked. (See 5.4.4 of
the Core Specification.)
Option B is incorrect. It will NOT because setRollbackOnly is used. (See 5.4.4 of the Core Specification.)
Option C is correct. The setRollbackOnly ensures that no acknowledgment is sent, so the JMS server tries
to resend.
Given an excerpt of a Book entity (it is just missing the import statements):
10. @Entity
12. @Id
23. }
D The enumeration or its field definition on lines 17, 18, or 19 is NOT valid.
Reference
Option B is correct. Adding it to line 21 does the job. java.util.Map is NOT a valid persistent field type
unless of course it is for a collection-based relationship. (See the end of 2.1. of the JPA Specification.)
Option C is incorrect. The visibilities are private/protected/package which is fine. (See 2.1 of the JPA
Specification.) Option D is incorrect. The field definition is fine. (See 9.1.21 of the JPA Specification.)
10. @Embeddable
12. int x;
13. String y;
14. /* ... */
15. }
It is referenced from an entity class Hotel. Given the full excerpt containing the reference:
20. @Entity
22. //
26. /* ... */
27. }
C A different entity class, for example Shop, can also use the Mattress class as the type of one of its
persistent fields.
D The Mattress class cannot be used as the type of a field, when that field is annotated with
@EmbeddedId.
Reference Option A is incorrect. It should NOT define one. These classes do not have an identity,
but are associated with their referencing entity. (See 2.1.5 of the JPA Specification and also see the
footnote on 9.1.14.) Option B is incorrect. Just having the type annotated is enough. (See 2.1.6 of the
JPA Specification.) Option C is correct. Although 2.1.5 JPA Specification says "attempting to share an
embedded object across entities has undefined semantics" this refers to instances. It is acceptable for
the type to be shared (promoting reuse).
Option D is incorrect. It can be used because it has the @Embeddable attribute. (See 9.1.14.)
Location: ... > Section 5: Java Persistence API Entities > Objective 5.3 > Question 26
All of the entities in a persistence unit have the following two lines defining their primary keys:
The deployment descriptor has only the following few lines pertaining to primary keys:
20. <table-generator>
21. <name>MyGenerator</name>
22. <table>MyTable</table>
23. <pk-column-name>NAME</pk-column-name>
24. </table-generator>
A Only AUTO, TABLE, and IDENTITY generation types are made available by a persistence provider.
B The different entities within the persistence unit can share the same generator.
C The provider must generate a suite of tables when it processes the table-generator tag.
D The MyTable table is accessed each time a new entity is persisted to the database to ensure that a
unique identifier is assigned for the entity.
Reference
Option B is correct. It can. A single table-generator stores a number of ID sequences (such as the last
chunk of IDs used), one for each entity.
Option C is incorrect. The table-generator tag does not generator tables. It defines tables that will be
used to generate ID values.
Option D is incorrect. Chunks of ID values are allocated. The default chunk size is 50. (See 9.1.38.)
Location: ... > Section 5: Java Persistence API Entities > Objective 5.4 > Question 27
There are two tables in a database, Celery and Carrot. Celery contains a foreign key to Carrot. Each table
has a primary key, and there are no other constraints on the tables. No descriptors are used, and in the
following options each scenario depicts all the mapping information pertaining to the relationship.
A @Entity Celery {
/* ... */
@Entity Carrot {
@ManyToOne
Celery celery;
/* ... */
B @Entity Celery {
@ManyToOne
Carrot carrot;
/* ... */
@Entity Carrot {
/* ... */
C @Entity Celery {
@OneToOne
Carrot carrot;
/* ... */
} @Entity Carrot {
/* ... */
}
D @Entity Celery {
/* ... */
@Entity Carrot {
@OneToOne
Carrot carrot;
/* ... */
Reference
Option B is correct. The question states that Celery has a foreign key constraint to Carrot. So entities
mapped to Celery are able to point to entities mapped to Carrot. This is almost enough for a
unidirectional one-to-one mapping used in Option C and Option D, but for a *one-to-one* mapping you
need a *unique key constraint* on the foreign key, but that does not exist here, so it is NOT Option C or
Option D. Furthermore, unidirectional mappings only have an owning side, which contains the foreign
key). In this case, the owning side is Celery. (See 2.1.8.3 of the JPA Specification.) Option A is incorrect
because of this too. The unidirectional mapping must have an owning side containing the foreign key
(see 2.1.8.3.1 of the JPA Specification) and in Option A the @ManyToOne is on the incorrect entity
(table). (See 2.1.8.3.2 for another example.)
Location: ... > Section 5: Java Persistence API Entities > Objective 5.5 > Question 28
A domain model comprises two entities: Dog and Flea. The developer is required to construct these
entities so that the Dog and Flea entities are in a unidirectional one-to-many relationship.
A domain model comprises two entities: Dog and Flea. The developer is required to construct these
entities so that the Dog and Flea entities are in a unidirectional one-to-many relationship.
Reference
Option D is correct.
For an example of this scenario, see 2.1.8.5 and 2.1.8.5.1 of the JPA Specification. Option D is the option
that is NOT true here. The owning side will be Dog. The @OnetoMany annotation will certainly be
placed on Dog, and the @ManyToOne annotation must NOT be used because this relationship is
unidirectional.
Location: ... > Section 5: Java Persistence API Entities > Objective 5.6 > Question 29
Here are excerpts from a class hierarchy, where some of the classes are abstract and others concrete:
10. @MappedSuperclass
13. }
22. }
30. @Entity
33. /* ... */
34. }
Which statements about these classes is correct?
Reference
Option C is correct, which makes Option B and Option A incorrect. (See 2.1.9.3.) The non-entity class
FooSuper simply contributes behavior (in this case, none), and NOT persistent state.
Option D is incorrect. It cannot be the target. (See 2.1.9.2 of the JPA Specification.)
Option E is incorrect. The developer cannot persist a non-entity superclass. (See 2.1.9.2 of the JPA
Specification.)
Location: ... > Section 5: Java Persistence API Entities > Objective 5.7 > Question 30
10. @Entity
13. @Column(name="NAMEBOOK")
16. }
The associated descriptor file has the following snippet pertaining to this entity:
22. <attributes>
25. </basic>
27. <temporal>DATE</temporal>
28. </basic>
29. </attributes>
30. </entity>
A The descriptor will ensure that the table BOOKTB is used to map the entity Book, and that bookName
is mapped to column NAMEBOOK within this table.
B The descriptor ensures that the table BOOKTB is used to map the entity Book, and that bookName is
mapped to column TOMENAME within this table.
C This persistent unit does NOT deploy because an annotation is missing on the Book entity class.
D This persistent unit does NOT deploy because the descriptor information is NOT complete.
Reference
Option D is correct. The entity has the metadata-complete attribute, which means that the metadata
should be completely specified within the descriptor as the metadata on the class will be ignored. This is
an entity, therefore a primary key must be indicated, and the descriptor does not do this. As a result,
you cannot successfully deploy this code. (See 10.1.3.1.)
Option A, B, and C are incorrect because D is correct. The descriptor does NOT ensure that a particular
table or column is used because the descriptor will NOT allow this to be deployed.
Location: ... > Section 6: Java Persistence Entity Operations > Objective 6.1 > Question 31
A The merge, persist, remove, and getReference methods must be invoked within a transaction context.
B It is safe (no exception is thrown) to call merge or getTransaction on a JTA EntityManager instance.
D Runtime exceptions thrown by the refresh and createQuery methods of the EntityManager interface
do NOT cause the transaction to be rolled back.
Reference
Option A is incorrect. getReference does NOT need to be invoked within a transaction context. (See
3.1.1 of the JPA Specification.)
Option B is incorrect. An exception is thrown if you call getTransaction on a JTA transaction manager.
(See 3.1.1 interface listing.)
Option C is correct. Even though in general this behaves as a lazy proxy to an entity, an
EntityNotFoundException can be thrown. (See interface documentation in 3.1.1 of the JPA
Specification.) Option D is incorrect. It causes the exception to roll back. (See 3.1.1.)
Location: ... > Section 6: Java Persistence Entity Operations > Objective 6.2 > Question 32
Entities can be in a new, managed, detached, or removed state. Which statement is correct about these
states?
B Detached entities are associated with a persistence context, but no longer have a persistent identity.
C If an entity in the new state is removed, any cascaded removes to referenced objects from this new
entity, are still carried out.
D Immediately removing an entity after creating and persisting it, within the same transaction, causes
an IllegalArgumentException to be thrown.
Reference
Option B is incorrect. They are no longer associated with a persistent context, but do have a persistent
identity. (See 3.2 of the JPA Specification.)
Option C is correct. Cascades work on objects that are still new! (See 3.2.2 of the JPA Specification.)
Option D is incorrect. If an entity has just been created, it is in the new state. It is then persisted, so it
moves to a managed state. Removing managed entities is allowed. They become removed. (See 3.2.2 of
the JPA Specification.)
Location: ... > Section 6: Java Persistence Entity Operations > Objective 6.3 > Question 33
Which statement does NOT correctly identify when an entity becomes detached when a transaction-
scoped persistence context is used?
B Pre-existing managed entities (instances that were persistent in the database at the start of the
transaction) become detached when the transaction commits.
D If the entity manager is used outside of a transaction, all entities loaded from the database by the
EntityManager.find method of that entity manager are detached.
Reference
Option A and Option B both reflect what actually happens to managed instances at transaction
commit/rollback. (See 3.3.1 and 3.3.2 of the JPA Specification.)
Option C is correct because EntityManager.flush does NOT cause all managed entities to become
detached. It simply synchronizes the context with the database. (See 3.1.1.) Option D reflects what
actually happens. They are detached. It is legal to do this. (See notes on find in 3.1 of the JPA
Specification.)
Location: ... > Section 6: Java Persistence Entity Operations > Objective 6.4 > Question 34
Given a method from a stateless session bean manipulating Book entities that have a persistent name
field. Moreover, the Book entity has a life-cycle callback for PrePersist, PostPersist, PreRemove,
PostRemove, and PostUpdate. It runs in a REQUIRES_NEW transactional context, and em is bound to a
entity manager:
12. em.persist(b);
14. d.setBookName("Jive");
15. em.remove(d);
17. em.persist(q);
18. }
The method completes without any exception and the transaction commits.
Which statement corresponds to a possible order of callback method invocation that would occur during
this method?
Reference The key here is that you can rely on the order of some life-cycle callbacks (because they
are invoked as part of the synchronous persist/remove operations) but NOT on others. For example,
PostRemove, which is invoked after the actual database change occurs, might be at some stage in the
future. Option A is incorrect because of the PostLoad at the start. Nothing loads any entity before an
entry persists here. Option B is incorrect because of the reordering. The Specification clearly states that
PrePersist and PreRemove are invoked before the respective EntityManager persist and remove
operations are executed. So the order of PreRemove and PrePersist must follow the order of the calls,
which in this case is persist (line 12), remove (line 15), persist (line 17). Option C is correct. The order of
the PrePersists and PreRemoves follow the code. The update might seem to occur in an odd place, but it
is quite valid because the Specification indicates that it occurs after the *database* update, which can
occur at any time that the state is flushed. Finally, the PostRemove occur too because of the
corresponding PreRemove on line 15. As the Specification indicates, these can occur directly after the
operation or at transaction commit time (as in this case). (See 3.5.2 of the JPA Specification.) Option D is
incorrect because of the reordering. See Option B. There are other valid orders. For example, you can
remove PostUpdate from Option C.
Location: ... > Section 6: Java Persistence Entity Operations > Objective 6.5 > Question 35
Reference
Option A is incorrect. It assumes a read-committed isolation level. (See 3.4 of the JPA Specification.)
Option B is incorrect. There are no restrictions similar to this in the Specification. It works in an extended
context. Option C is correct. This is the general use case for merging detached objects. (See 3.4.2 of the
JPA Specification.)
Option D is incorrect. They can be generated when the flush method is called too.
Location: ... > Section 7: Persistence Units and Persistence Contexts > Objective 7.1 > Question 36
15. em.getTransaction().begin();
18. em.getTransaction().commit();
19. em.close();
20. emf.close();
21. }
22. }
Assume that the Book entity exists, that the appropriate configuration files are in place, and that there is
a Book entity in the persistent store.
Which statement about this code, and about resource-local/JTA entity managers in general, is correct?
C It is illegal to write this sort of resource-local entity manager code in a Java EE environment.
D The default entity-manager transaction type should have been set on line 13.
Option B is incorrect. This is how you use the EntityTransaction interface. (See 5.5.2.1 of the JPA
Specification.)
Option C is incorrect. The developer is allowed to use resource-local entity managers in a Java EE
environment. (See 6.2.1.2 of the JPA Specification.)
Location: ... > Section 7: Persistence Units and Persistence Contexts > Objective 7.2 > Question 37
A Container-managed persistence contexts propagate with the JTA transaction within the container.
B Container-managed persistence contexts can have a lifetime that is scoped to a single transaction or
that spans multiple transactions.
C The developer can create extended persistence contexts in a stateful session bean.
D The developer can create extended persistence contexts in a stateless session bean.
Reference
Option D is the option that is NOT true. The developer can only create extended persistence contexts in
a stateful session bean. (See 5.6.2 of the JPA Specification.) Option A and Option B are correct. It
propagates with the JTA transaction and it can be transaction or extended scoped. (See 5.6 of the JPA
Specification.) Option C is also correct. (See 5.6.2 of the JPA Specification.)
Location: ... > Section 7: Persistence Units and Persistence Contexts > Objective 7.3 > Question 38
Which method of the EntityManager API is used to control the life-cycle of an application-managed
persistence context?
A EntityManager.remove
B EntityManager.refresh
C EntityManager.joinTransaction
D EntityManager.getReference
Reference
Option C is correct. For example, a JPA application-managed entity manager could be created outside
the scope of a JTA transaction and later associated with one. (See 5.7 and 3.1.1 of the JPA Specification.)
Other methods used to manage the entity manager include close, isOpen, and getTransaction. Option A,
B, and D are incorrect because remove, refresh, and getDelegate are NOT used to control the life-cycle
of (any kind of) persistence context, but rather to manage entities within the scope of a persistence
context.
Location: ... > Section 7: Persistence Units and Persistence Contexts > Objective 7.4 > Question 39
Given an excerpt from a session bean that uses a configured resource-local entity manager:
10. @Stateless
12. @PersistenceUnit(unitName="spammer")
14.
17. try {
19. em.getTransaction().begin();
20. em.persist(s);
21. em.getTransaction().commit();
23.
24. } finally {
25. em.close();
26. }
27. }
28. }
Spam is an entity. Assume that the spammer persistence unit is set up correctly.
What happens when another session bean running on the same server, executing in a JTA transactional
context, makes a call to the createSpam method?
C The JTA transactional context is suspended on line 19 and a new transaction is created.
E If the datasources underlying the entity manager are appropriately configured, the code executes
without error.
Reference Option E is correct. The key here is that this is a *resource-local* entity manager. So the
transaction is mapped to the resource that underlies the entity manager, probably a datasource in this
case. The other important point to note is that these entity managers are unaware of any JTA
transaction that might be taking place. (See 5.5 and 5.5.2 of the JPA Specification.) The code is fine and
is a good example of using an application-managed, resource-local entity manager. However, the
developer should configure your datasources appropriately. In this example, the developer would
configure datasources appropriately by ensuring that the entity manager uses a non-JTA datasource.
Otherwise, conflicts occur.
Option A, B, C, and D are incorrect because no exceptions are generated, as explained above.
Location: ... > Section 7: Persistence Units and Persistence Contexts > Objective 7.5 > Question 40
A Every persistence unit must always have the persistence.xml and orm.xml configuration files.
B The persistence.xml file can be used to define more than one persistence unit.
C Mapping metadata for a class can be specified using annotations, or in the XML configuration files,
but NOT in both.
D When a persistence unit is packaged in a WAR, the persistence.xml file must be located in the /META-
INF directory off the root of the WAR package.
Reference
Option A is incorrect. orm.xml is optional. It is NOT needed. (See 6.2.1.6 of the JPA Specification.)
Option C is incorrect. The developer can specify mapping metadata using both annotations and XML
metadata. (See 6.2.1 of the JPA Specification.)
Option D is incorrect. It can either be in a jar file in WEB-INF/lib, or in the META-INF directory off the
WEB-INF/classes directory. (See 6.2 of the JPA Specification.)
Location: ... > Section 7: Persistence Units and Persistence Contexts > Objective 7.6 > Question 41
A PersistenceException
B RollbackException
C EntityExistsException
D NoResultException
E OptimisticLockException
Reference
Option A, B, C, and E are incorrect. (See 3.6.1 of the JPA Specification.) Although NoResultException is a
PersistenceException, it does NOT roll the transaction back. All the others do.
Location: ... > Section 8: Java Persistence Query Language > Objective 8.1 > Question 42
10. @Entity
13. @Id
15. /* ... */
16. }
The following code was written to find the sum and average number of children across all Koala entities
(assume the variable em is bound to a valid EntityManager instance):
A If there are no Koala entities in the database, the variable res is set to null after the code exits on line
22.
B If there are no Koala entities in the database, the variable res contains an array of two null values.
C If there are no Koala entities in the database, the variable res contains an array holding the values null
and 0 respectively.
D If there are Koala entities, the variable res contains an array with values of type Long and Double,
respectively.
Reference
Option B and Option D are correct. An array with two values of types Long and Double, respectively, is
returned. (See 4.8.4 of the JPA Specification.) If there are no entities, SUM and AVG return null,
respectively.
Option A, C, and E are incorrect because Option A and D are correct. In particular, the JPQL syntax is
valid and there is no runtime exception.
Location: ... > Section 8: Java Persistence Query Language > Objective 8.2 > Question 43
A User entity is in a one-to-many relationship with a Book entity. Given an excerpt from the Book entity
showing the relationship:
10. @Entity
12. @ManyToOne
13. @JoinColumn(name="user_id")
15. /* ... */
16. }
20. @Entity
24. }
A developer wants to retrieve all Book entities that are associated with User entities and writes the
following query:
B The syntax is valid, but the query does NOT return the correct set of books.
D The query only works if the metadata for the classes is changed.
Reference
Option C is correct. This is a valid query and indeed returns only those books that are assigned to users.
(See 4.4.5.) This is actually an instance of join_collection_valued_path_expression.
Option D is incorrect, the query works as expected with the above metadata.
Location: ... > Section 8: Java Persistence Query Language > Objective 8.3 > Question 44
A domain model for a corporation includes a User entity that is in a one-to-many relationship with a Pen
entity. A developer wants to select all User entities that have a single Pen.
Reference Option A and Option C are correct. For the ALL operator, the comparison on the left side
of the = operator and all subquery results must be true for the overall condition to be true. In this case
the subquery returns the count of the pens for the particular user, so the entire predicate is true when
the user has a single pen. For the same reason, the ANY operator will also work in this case. (See 4.6.14
of the JPA Specification.)
Option B is syntactically incorrect. ANY should be part of a predicate. (See the BNF for
comparison_expression in 4.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:
The following code is found in a stateless session bean, intended to delete all leopards:
22. }
B The executeUpdate method is the wrong method to call on the Query object under these
circumstances.
Reference
Option D is correct. A bulk update similar to this maps directly to a database operation. In this case, the
Spot entity is in a bidirectional mapping and so foreign keys will exist. As a result, deleting the Leopard
records causes a foreign key constraint (depending on database and JPA implementation).
Option B is incorrect. This is the correct way to execute the update. (See 3.6.1 of the JPA Specification.)
Option C 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.)
Location: ... > Section 8: Java Persistence Query Language > Objective 8.5 > Question 46
10. @Entity
14. }
Each of the following Java technology statements create Query objects, where em refers to an entity
manager.
A em.createNativeQuery("myname").setParameter(1, "val=20")
B em.createNamedQuery("myname").setParameter("val", 20)
C em.createNamedQuery("myname").setParameter(20, 1)
D em.createNamedQuery("myname").setParameter(1, 20)
Option A, C, and D are incorrect because they use an incorrect syntax for providing the parameter value.
Location: ... > Section 8: Java Persistence Query Language > Objective 8.6 > Question 47
A persistence unit defines a domain model consisting of User and Password entities. Given an excerpt
from the Password entity:
10. @Entity
14. /* ... */
23. }
40. @Entity
41. @NamedQueries({
42. @NamedQuery(name="bar",
44. })
49. }
Reference Option A is correct. (See 3.1.1 and 3.6.4 of the JPA Specification.) Named queries are
scoped to a persistence unit. It does not matter that the query foo references User, or that bar is
defined on User and used in Password. The query is also created and executed correctly as per 3.1.1.
Location: ... > Section 9: Transactions > Objective 9.1 > Question 48
A A Java technology client using client-managed transaction demarcation can NOT ensure atomic
updates across multiple databases residing at multiple EJB servers.
C A stateful session bean using bean-managed transactions must commit the transaction before a
business method returns.
D A session bean instance that uses bean-managed transactions must NOT invoke the commit or
rollback method on the java.sql.Connection interface.
Reference Option A is incorrect. A Java client can do this. (See 13.2.4 of the Core Specification for
an example.)
Option B is incorrect. It only supports flat. (See 13.1.2 of the Core Specification.)
Option C is incorrect. This is true for stateless beans, NOT stateful ones. (See 13.3.3 of the Core
Specification.)
Option D is correct. The developer should NOT use resource-manager specific transaction demarcation
APIs. (See 13.3.3 of the Core Specification.)
Location: ... > Section 9: Transactions > Objective 9.2 > Question 49
10. @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)
14. }
30. @Stateless
31. @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)
34. @TransactionAttribute(TransactionAttributeType.SUPPORTS)
36. }
No deployment descriptor is used. foo, bar, and zip are business methods defined in interface MyI.
Which statement correctly defines the transaction attributes assigned to the methods foo, bar and zip
respectively?
Reference
Option B is correct. (See the rules in 13.3.7.1 of the Core Specification.) foo will be NOT_SUPPORTED
because of the class-level attribute and because it overrides. bar will be SUPPORTS because that is the
transaction attribute applied to the method. zip will be REQUIRES_NEW because that is the attribute
assigned in the superclass and it is NOT overridden. Attributes applied to a superclass only apply to
business methods defined in that superclass.
Option A, C, and D are incorrect orders because Option B is the correct one.
Location: ... > Section 9: Transactions > Objective 9.3 > Question 50
B An enterprise bean's timeout callback method can only have a REQUIRED, REQUIRES_NEW, or
NOT_SUPPORTED transaction attribute.
Reference
Option B is correct.
Location: ... > Section 9: Transactions > Objective 9.4 > Question 51
10. @Stateful
11. @TransactionAttribute(TransactionAttributeType.REQUIRED)
13. @TransactionAttribute(TransactionAttributeType.MANDATORY)
16. }
The two chromosome methods are business methods. Here are the transactional settings found in the
deployment descriptor for this bean:
10.
11.
12. GenomeBean
13. chromosome
14.
15. String
16. String
17.
18.
19. REQUIRES_NEW
20.
21.
22.
23. GenomeBean
24. *
25.
26. SUPPORTS
27.
What are the transactional behaviors placed on the two chromosome methods?
Reference
Option C is correct. The descriptors override/add to the metadata annotations. In this case, they
override both. The transaction tag starting on line 21 ensures that both methods have a SUPPORTS
transaction. The transaction tag starting on line 11 overrides this for the chromosome(String x, String y)
method because this style takes precedence. (See 13.3.7.2.1 of the Core Specification.)
Options A, B, D, and E are incorrect because they do not follow this setting, as described in Option C.
Location: ... > Section 9: Transactions > Objective 9.5 > Question 52
10. @Stateful
16. @Remove
18. }
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)
22. ms.inc();
23. }
Reference Option A is correct. doIt is called first, as indicated in the question. Because this is now
in a transactional context, the container invokes afterBegin before it invokes the business method. (See
13.6.2.11 of the Core Specification). The business method is annotated with @Remove, so the instance
moves to "does NOT exist" immediately, without calling beforeCompletion/afterCompletion. (see Figure
5 and text in 4.4 of the Core Specification.) Option B, C, D, and E do not agree with this order, so they are
incorrect.
Location: ... > Section 10: Exceptions > Objective 10.1 > Question 53
Which statement is true regarding business method AroundInvoke interceptors in a stateful session
bean?
D If a system exception escapes the interceptor chain of AroundInvoke methods, the bean instance is
discarded.
Option C is incorrect because they can only throw checked exceptions that the business method that
they are intercepting can throw.
Option D is correct.
Location: ... > Section 10: Exceptions > Objective 10.2 > Question 54
Which exception, when thrown in a transactional business method of a session bean (and declared in
the throws clause of the method), does NOT cause the transaction to roll back?
A javax.persistence.PersistenceException
B javax.ejb.EJBException
C java.lang.RuntimeException
D java.sql.SQLException
Reference Options A, B, and C are all plain instances of java.lang.RuntimeException. These all cause
a transaction to roll back (14.2.2 Core Specification) unless they are application exceptions too, which
none of these are.
Location: ... > Section 10: Exceptions > Objective 10.3 > Question 55
10. @Stateful
11. @TransactionAttribute(TransactionAttributeType.REQUIRED)
13. @PreDestroy
14. public void slashstar() {}
17. }
18. }
It has no descriptor. A client makes a call to oops, which runs in the context of the client's transaction.
What action would you expect the container to perform, if any, after this transaction is thrown?
E It is the responsibility of the bean provider to properly catch and handle such exceptions.
Option D is incorrect. PreDestroy methods are not executed. (See Note C in that table and other places
in the Specification.)
Location: ... > Section 10: Exceptions > Objective 10.4 > Question 56
Given an interface:
4. @Local
7. }
Given an excerpt from a stateful session bean that implements this business interface:
9. @Stateful
10. @TransactionAttribute(TransactionAttributeType.REQUIRED)
14. ctx.getRollbackOnly();
15. ctx.getEJBOjbect();
16. ctx.getEJBHome();
18. }
50. }
Reference
Option A is incorrect because there will be a meaningful transaction context. It is a stateful session bean
with a REQUIRED transaction attribute.
Option B is correct. Neither getEJBObject() nor getEJBLocalObject() can be called in this case. Both apply
to the EJB 2.x (and earlier) client view, NOT the EJB 3.0
business interface view. The way to get a reference to a 3.0 business interface from the SessionContext
is through the getBusinessObject(Class<T> businessInterface).
Option C and Option D are incorrect because an exception is thrown on line 15 (Option B) and so
execution never reached any further.
Location: ... > Section 10: Exceptions > Objective 10.5 > Question 57
A client, executing in the context of a transaction, makes a call to a session bean and receives a
java.rmi.RemoteException.
B The business method has completed, but there was a communication problem after completion.
D The client never receives such an exception. It is always wrapped in another transaction type.
Option A is incorrect. It is NOT certain that the method has NOT completed. It might have.
Option B is incorrect. It is NOT certain that the method has completed either.
Location: ... > Section 11: Security Management > Objective 11.1 > Question 58
10. @Stateless
11. @RolesAllowed("JAMES")
13. @DenyAll
14. }
The methods spy and eye are defined in the business interface for this bean. The bean has an
accompanying descriptor, and here is an excerpt of the relevant security portion:
<method-permission>
<role-name>BOND</role-name>
<method>
<ejb-name>YourBean</ejb-name>
<method-name>eye</method-name>
</method>
Which security roles can access which methods?
Reference Option F is correct. The RolesAllowed annotation tell us that the security role JAMES can
access the bean (all methods). (See 17.3.2.1 of the Core Specification.) DenyAll retracts that permission
for the spy method (so nobody can access it). The deployment descriptor overrides the annotation
(17.3.2.2) and so only BOND is able to access eye, NOT JAMES.
Option A,B,C,D,E are incorrect because F is correct. See the reasoning for Option F.
Location: ... > Section 11: Security Management > Objective 11.2 > Question 59
Which two roles are responsible for creating or modifying security roles in a bean's annotations or
deployment descriptor? (Choose two.)
A Bean Provider
B Application Assembler
C Deployer
F System Administrator
Reference Option A and B are correct. (See 17.3.1.) All the other options are incorrect because the
correct options are A and B.
Location: ... > Section 11: Security Management > Objective 11.3 > Question 60
Assume ctx is a context object injected into a bean (SessionContext for session beans, EntityContext for
entities).
Option A does NOT cause an exception to be thrown. (See Table 2 in 4.5.2 of the Core Specification.)
Option B does NOT cause an exception to be thrown either. (See Table 1 of the Core Specification.) In
contrast to stateless beans, this is a meaningful security context.
Option C does NOT cause an exception. (See Table 4, section 8.5.6, of the Core Specification.)
Option D causes an exception. This is not a meaningful security context. (See Table 2 in 4.5.2 of the Core
Specification.)
Location: ... > Section 11: Security Management > Objective 11.4 > Question 61
10. <session>
11. <ejb-name>EN</ejb-name>
12. <ejb-class>com.sun.ejb.EClassBean</ejb-class>
13. <security-role-ref>
14. <role-name>AGENTN</role-name>
15. <role-link>AGENTL</role-link>
16. </security-role-ref>
17. </session>
If ctx is an injected SessionContext, which of the following calls would you expect to see in the bean
implementation given this descriptor?
A ctx.getCallerPrincipal()=="AGENTL"
B ctx.getCallerPrincipal()=="AGENTN"
C ctx.isCallerInRole("AGENTN")
D ctx.isCallerInRole("AGENTL")
Reference
Option D is incorrect because the role-link links the reference role used in the code (AGENTN) to a real
security role (AGENTL in this case).
Option A and B are incorrect because getCallerPrincipal is NOT used in this way. (See 17.2.5.1 of the
Core Specification.)