scbcd-5 q&a with explanations - 2

QUESTIONS FOR SCBCD 5.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.)

A EJB 2.1 APIs

B Common Annotations

C JavaServer Faces APIs

D JavaServer Pages APIs

E Java Data Objects APIs

Reference

Options A and B are correct. (See the Simplified Specification 2.2. and the Core Specification 21.1.1.)

Option C, D, and E are NOT mentioned in the Specifications so are incorrect.


What programming restrictions are defined in the EJB specifications?

A An enterprise bean must NOT attempt to listen on a socket.

B A session bean class must NOT have any superclasses and/or superinterfaces.

C An enterprise bean can directly read a file descriptor.

D An entity bean class need NOT implement a public zero-argument constructor.

Reference

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

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.)

Option D is incorrect because it must do so. (See section 8.6.2.)


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

C Enterprise Bean Provider

D Persistence Provider

E EJB Container 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.


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.

What files must be placed in this ejb-client JAR for it to be valid?

A The ejb-jar file (by inclusion or by reference)

B The Television class (by inclusion or by reference)

C Stubs of all enterprise classes referenced by the ejb-client

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.

Option D is incorrect. This has nothing to do with EJB technology.


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?

A A conflicting-metadata exception will be thrown by the deployment tools.

B The deployment descriptor metadata will override the annotation metadata.

C The annotation metadata will override the deployment descriptor metadata.

D The result is NOT specified and will be vendor-specific.

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

Which statement about life-cycle callback methods is correct?

A Life-cycle callback methods must be implemented in the bean class.

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.

D Life-cycle callback methods can be declared as static.

Reference

See 3.4.1 Simplified Specification for all of these.

Option A is incorrect. They can be implemented in an interceptor class too.

Option B is correct.

Option C is incorrect. It can have multiple callback annotations.

Option D is incorrect. They cannot be static (or final).


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?

A The specification states that the value will be undefined.

B It will be set to null.

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 A is incorrect because it will be defined. See Option C.

Option B is incorrect because it will be defined. See Option C.

Option D is incorrect because the interceptor state is bound to the state of the session bean in question, NOT some other arbitrary one.


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.)

A @Resource public javax.sql.DataSource getMyDS() { return myDS; } public void setFoo(javax.sql.DataSource myDS) { this.myDS = myDS; }

B @Resource (type=javax.sql.DataSource.class) Object myDataSource;

C @Resource(name="myDS") private javax.sql.DataSource myDS;

D @Resource(name="myDS") public javax.sql.DataSource myDS;

E @EJB public javax.sql.DataSource myDS;

Reference

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.


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.)

A Stateless session beans

B Stateful session beans

C EJB 2.1 entity beans

D EJB 3.0 entities

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.


Consider the following excerpt from a session bean with one business method, roast:

10. @Stateful

11. public class OvenBean implement Oven {

12. @Resource SessionContext ctx;

13. @Resource public void setTemperature(Temp temp) {

14. //

15. }

20. public void roast() {

21.

22. }

23. @PostConstruct

24. void potatoes() {

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.


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 A is correct. (See section 9.3 in the Simplified Specification.)

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.)

Option D is incorrect. There is no such requirement.

Location: ... > Objective 3.1 > Question 13

Which statement characterizes stateful session beans?

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

B They require home interfaces.

C When a client looks up a stateful session bean in the JNDI, the same bean is returned every time.

D They are asynchronous message consumers.

Reference

Option A is correct. (See 5.1.4.)

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.)


Which statement is correct about session beans?

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.)

Option C is correct. (See 3.2 of the Simplified Specification.)

Option D is incorrect. (See 3.2 of the Simplified Specification.)


Given an interface:

5. public interface ValueInt {

6. public int getVal();

7. int getBarPackage();

8. }

Here is an excerpt from a stateless session bean that implements this interface:

10. @Stateless

11. public class FloatBean implements ValueInt {

12. public int getVal() { return 4; }

13. public int getBarPackage() { return 2; }

50. }

What methods are exposed to local clients of this stateless session bean?

A no methods are exposed

B getVal

C getBar

D getVal and getBarPackage

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.


A programmer constructs a stateful session bean that contains, in addition to the business methods, the following three life-cycle callback methods:

@PostConstruct

public void initConnection() {

// add a new unique record into a database, and keep primary key

// in the local state of this stateful session bean.

}

@PreDestroy

public void zapConnection() {

// retrieve the primary key from the local state of this stateful session

// bean and remove the record.

}

@Remove

public void zap() {

}

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.

What circumstances lead to the database record NOT being deleted?

A A timeout of the bean occurs while the bean instance is active.

B The method zap is called while the bean instance is active.

C A timeout of the bean occurs while the bean instance is passivated.

D The method zap is called when the bean instance is passivated.

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.


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.

Which statement successfully retrieves the datasource?

A @Resource DataSource ds;

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.)


Which statement about exposing session beans as web services is correct?

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.

C EJB interceptors cannot be used in beans exposed as web services.

D Session beans that provide a web services client view cannot make use of JAX-RPC message handlers.

Reference

Option A is incorrect. Only stateless beans can be.

Option B is correct. (See 4.3.6 of the Core Specification.) SessionContext.getMessageContext in fact.

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:

10. @EJB SSb fee;

11. @EJB SSb fi;

12. if (fee.equals(fee)) { /* some code */ }

13. if (fee.equals(fi)) { /* some code */ }

Which statement is correct about this testing?

A The developer should NOT compare business interface references with the equals method.

B The tests on line 12 and 13 both always return false.

C The test on line 12 always succeeds with true, but the test on line 13 always fails with false.

D Both tests always succeed with true.

Reference Option A is incorrect. The code is valid. (See 3.4.5.2 of the Core Specification.)

Option B is incorrect because D is true. Option C is incorrect because D is true.

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.)


A message-driven bean can have an instance of a MessageDrivenContext injected.

Which method can be successfully invoked on this interface from a message-driven bean?

A getEJBHome

B getCallerPrincipal

C isCallerInRole

D getEJBLocalHome

Reference

Option B is correct. (See 5.4.4 of the Core Specification.)

Option A, C, and D should NOT be called. (See 5.4.4 of the Core Specification.)


Which statement is true about message-driven beans?

A A message-driven bean can register with the EJB Timer Service for timeout callback notifications.

B A message-driven bean must implement the javax.ejb.MessageDrivenBean interface.

C Message-driven beans only support the PostConstruct life-cycle callback interceptor.

D Message-driven beans do NOT support the AroundInvoke business method interceptors.

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

Option B is incorrect. This is optional. (See 5.4.6 of the Core Specification.)

Option C is incorrect. It also supports PreDestroy. (See 5.4.5 of the Core Specification.)

Option D is incorrect. They do. (See 5.4.9 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.)

A If a message is received, the container automatically acknowledges it.

B If a message is received, the container does NOT automatically acknowledge it.

C Messages will NOT be missed, even if the EJB server is NOT running.

D Messages can be missed if the EJB server is NOT running.

E Specifying subscription durability for a topic has no effect.

Reference

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

Option D is correct. (See 5.4.16 of the Core Specification.) So the default is non-durable subscription and automatic acknowledgment.

Option C is incorrect because D is correct. Option B is incorrect because A is true.

Option E is incorrect. The developer certainly can specify a durability for a topic. (See 5.14.16 of the Core Specification.)


Given a snippet of a JMS message-driven bean, configured to listen on a queue.

@MessageDriven

public class LetterBean implements MessageListener {

@Resource MessageDrivenContext ctx;

public void onMessage(Message msg) {

ctx.setRollbackOnly();

}

}

A JMS server receives a message and delivers it to this queue. After executing the onMessage method, no exceptions are thrown.

Which statement is correct about this message-driven bean?

A The message-bean is using bean-managed transactions.

B The server receives an acknowledgment sent by the LetterBean instance.

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.

Option D is incorrect. (See 5.4.17 for when this occurs.)

Location: ... > Section 5: Java Persistence API Entities > Objective 5.1 > Question 24

Given an excerpt of a Book entity (it is just missing the import statements):

10. @Entity

11. public class Book implements Serializable {

12. @Id

13. @GeneratedValue(strategy = GenerationType.AUTO)

14. private Integer id;

15. String bookName;

16. protected int price;

17. enum Status {IN, OUT};

18. @Enumerated( EnumType.ORDINAL )

19. Status status;

20. transient int bar;

21. java.util.Map<Integer, String> comments;

22. protected Book() {};

23. }

No descriptors are used.

Which statement is correct about this entity?

A There is an error on line 11. It must NOT implement Serializable.

B Adding a single @Transient annotation makes this entity valid.

C The visibility declarations on some of the variables causes an exception.

D The enumeration or its field definition on lines 17, 18, or 19 is NOT valid.

E There is an error in the identity definition on lines 12, 13, or 14.

Reference

Option A is incorrect. It can. (See 2.1 of the JPA Specification.)

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.)

Option E is incorrect. This identity definition is fine.


Given an excerpt from an embeddable class:

10. @Embeddable

11. public class Mattress {

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

21. public class Hotel {

22. //

23. Mattress spring;

24. public Mattress getSpring() { return spring; }

25. public void setSpring(Mattress bounce) { spring = bounce; }

26. /* ... */

27. }

No deployment descriptors are used.

Which statement is correct about this class?

A The Mattress class should define an identity field.

B An annotation needs to be placed on line 22 for the Hotel entity to be valid.

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.)


All of the entities in a persistence unit have the following two lines defining their primary keys:

10. @GeneratedValue(generator="MyGenerator", strategy = GenerationType.TABLE)

11. private int id;

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>

Which statement is correct?

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

See 9.1.38 and 9.19 of JPA Specification.

Option A is incorrect. There is also SEQUENCE.

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.)


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.

Which entities accurately model this database scenario?

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.)


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.

Which statement about implementing this model is NOT correct?

A The @OneToMany annotation must be placed in the Dog entity.

B The @ManyToOne annotation must NOT be used on the Flea entity.

C A join table can be used to implement this relationship.

D The Flea entity will be the owning side of the 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.

Which statement about implementing this model is NOT correct?

A The @OneToMany annotation must be placed in the Dog entity.

B The @ManyToOne annotation must NOT be used on the Flea entity.

C A join table can be used to implement this relationship.

D The Flea entity will be the owning side of the 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.


Here are excerpts from a class hierarchy, where some of the classes are abstract and others concrete:

10. @MappedSuperclass

11. public abstract class FooSuperDuper {

12. int foosuperduper;

13. }

20. public class FooSuper extends FooSuperDuper{

21. int foosuper;

22. }

30. @Entity

31. public class Foo extends FooSuper {

32. int foo;

33. /* ... */

34. }

Which statements about these classes is correct?

A All of the fields foo, foosuper, and foosuperduper will be persisted.

B Only the fields foo and foosuper will be persisted.

C Only the fields foo and foosuperduper will be persisted.

D FooSuperDuper can be the target of a persistent relationship defined in a different entity.

E FooSuper instances can be persisted.

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.)


Given the definition for an entity, Book:

10. @Entity

11. public class Book {

12. @Id Integer id;

13. @Column(name="NAMEBOOK")

14. String bookName;

15. public java.util.Date loanDate;

16. }

The associated descriptor file has the following snippet pertaining to this entity:

20. <entity class="Book" metadata-complete="true">

21. <table name="BOOKTB"/>

22. <attributes>

23. <basic name="bookName">

24. <column name="TOMENAME"/>

25. </basic>

26. <basic name="loanDate">

27. <temporal>DATE</temporal>

28. </basic>

29. </attributes>

30. </entity>

No other parts of the deployment descriptor affect this configuration.

Which statement about the persistent unit and descriptor is correct?

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

Which statement is correct about the EntityManager API?

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.

C The getReference method may throw an EntityNotFoundException.

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.)


Entities can be in a new, managed, detached, or removed state. Which statement is correct about these states?

A Removing an entity in the removed state, causes an IllegalArgumentException to be thrown.

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 A is incorrect. It is just ignored. (See 3.2.2 of the JPA Specification.)

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.)


Which statement does NOT correctly identify when an entity becomes detached when a transaction-scoped persistence context is used?

A Managed entities become detached when the transaction commits.

B Pre-existing managed entities (instances that were persistent in the database at the start of the transaction) become detached when the transaction commits.

C Executing EntityManager.clear or EntityManager.flush causes all managed entities to become detached.

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.)


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:

10. public void bookDance() {

11. Book b = new Book("Tango");

12. em.persist(b);

13. Book d = (Book) em.createQuery("select b from Book b").getSingleResult();

14. d.setBookName("Jive");

15. em.remove(d);

16. Book q = new Book("Salsa");

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?

A PostLoad, PrePersist, PostPersist, PreRemove, PrePersist, PostPersist, PostRemove

B PrePersist, PostPersist, PrePersist, PostPersist, PreRemove, PostRemove

C PrePersist, PostPersist, PreRemove, PrePersist, PostUpdate, PostPersist, PostRemove

D PrePersist, PostPersist, PostLoad, PrePersist, PostPersist, PreRemove, PostUpdate, PostRemove

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.


Which statement about locking is correct?

A JPA assumes a default repeated-read database isolation level.

B Optimistic locking cannot be used in extended persistence context.

C When an entity with a version attribute is flushed to the database, an OptimisticLockException is thrown if its version attribute is stale.

D Persistence providers only generate OptimisticLockException exceptions when a transaction commits.

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

Given: 10. import javax.persistence.*;

11. public class BookViews {

12. public static void main (String[] args) {

13. EntityManagerFactory emf = Persistence.createEntityManagerFactory("Book");

14. EntityManager em = emf.createEntityManager();

15. em.getTransaction().begin();

16. Book b = (Book) em.createQuery("SELECT b FROM Book b").getSingleResult();

17. b.setAccessed(b.getAccessed() + 1);

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?

A This code compiles and executes fine in a Java SE environment.

B The calls on line 15 and 18 are illegal.

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.

Reference Option A is correct. It is an example of a resource-local entity manager being used.

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.)

Option D is incorrect. It defaults to resource-local in a Java SE environment such as this.


Which statement about container-managed persistence contexts is NOT correct?

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.)


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.


Given an excerpt from a session bean that uses a configured resource-local entity manager:

10. @Stateless

11. public class SpamBean implements SpamService {

12. @PersistenceUnit(unitName="spammer")

13. EntityManagerFactory emf;

14.

15. public void createSpam(String msg) {

16. EntityManager em = emf.createEntityManager();

17. try {

18. Spam s = new Spam(msg);

19. em.getTransaction().begin();

20. em.persist(s);

21. em.getTransaction().commit();

22. } catch (Exception oh) {

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?

A An exception is thrown before line 16 is executed.

B An exception is thrown on line 19.

C The JTA transactional context is suspended on line 19 and a new transaction is created.

D An exception is thrown on line 21.

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.


Which statement about persistence units and packaging is correct?

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 B is correct. (See 6.2.)

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.)


Which exception will NOT cause an existing transaction to roll back?

A PersistenceException

B RollbackException

C EntityExistsException

D NoResultException

E OptimisticLockException

Reference

Option D is correct. (See 3.6.1 of the JPA Specification.)

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

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 sum and average number of children across all Koala entities (assume the variable em is bound to a valid EntityManager instance):

20. String query = "SELECT SUM(k.children), AVG(k.children) from Koala k";

21. Query q = em.createQuery(query);

22. Object[] res = (Object []) q.getSingleResult();

Which two statements are correct? (Choose two.)

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.

E This code throws a runtime exception.

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.


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

11. public class Book {

12. @ManyToOne

13. @JoinColumn(name="user_id")

14. private User owner;

15. /* ... */

16. }

Given an excerpt from the User entity showing the relationship:

20. @Entity

21. public class User {

22. @OneToMany(mappedBy="owner", fetch=FetchType.EAGER)

23. Collection<Book> books;

24. }

A developer wants to retrieve all Book entities that are associated with User entities and writes the following query:

SELECT b FROM User u JOIN u.books b

Which statement about this query is correct?

A The syntax of this query is invalid.

B The syntax is valid, but the query does NOT return the correct set of books.

C The query works and 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 A is incorrect, the syntax is valid.

Option B is incorrect, the query works as expected.

Option D is incorrect, the query works as expected with the above metadata.


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.

Which two queries will do this? (Choose two.)

A SELECT u from User u WHERE 1 = ANY(SELECT COUNT(p) from u.pens p)

B SELECT u from User u WHERE ANY(1 = SELECT COUNT(p) from u.pens p)

C SELECT u from User u WHERE 1 = ALL(SELECT COUNT(p) from u.pens p)

D SELECT u from User u WHERE SOME(1 = SELECT COUNT(p) from u.pens p)

E SELECT u from User u WHERE 1 = ANY(SELECT COUNT(u.pens))

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.)

Option D is syntactically incorrect. SOME should be part of a predicate.

Option E is syntactically incorrect. The SELECT statement is NOT complete.


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 stateless session bean, intended to delete all leopards:

20. public void removeAllLeopards() {

21. em.createQuery("DELETE FROM Leopard l").executeUpdate();

22. }

Which statement about this code is correct?

A The syntax of the DELETE FROM JPQL statement is invalid.

B The executeUpdate method is the wrong method to call on the Query object under these circumstances.

C It is NOT necessary to execute this code within a transaction.

D A foreign key integrity constraint can cause a PersistenceException

Reference

See 4.10 of JPA Specification.

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 A is incorrect. The syntax is fine.

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.)


Given the following entity bean:

10. @Entity

11. @NamedQuery(name="myname", query="select c from Crumble c where c.id=:val")

12. public class Crumble {

13. @Id private Integer id;

14. }

Each of the following Java technology statements create Query objects, where em refers to an entity manager.

Which statement returns a Crumble instance with a primary key of 20?

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)

Reference Option B is correct. (See section 3.6.4 of the JPA Specification.)

Option A, C, and D are incorrect because they use an incorrect syntax for providing the parameter value.


A persistence unit defines a domain model consisting of User and Password entities. Given an excerpt from the Password entity:

10. @Entity

11. @NamedQuery(name="foo", query="select u from User u where size=2")

12. public class Password {


14. /* ... */

20. public void doBusiness() {

21. Query q = em.createNamedQuery("bar");

22. List l = q.getResultList();

23. }

Given an excerpt from the User entity:

40. @Entity

41. @NamedQueries({

42. @NamedQuery(name="bar",

43. query="select u from User u")

44. })

45. public class User {


47. int size;

48. /* ... */

49. }

No descriptors are used.

Which statement about this code is correct?

A This compiles and executes without exceptions.

B There is an error on line 11.

C There is an error on lines 41, 42, and 43.

D There is an error on line 21

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.

Option B, C, and D are NOT correct because there are no errors.

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.

B The EJB architecture supports flat and hierarchical transactions.

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.)


Here are two excerpts from the implementation of a session bean:

10. @TransactionAttribute(TransactionAttributeType.REQUIRES_NEW)

11. public class MySuper {

12. public void foo() {}

13. public void zip() {}

14. }

30. @Stateless

31. @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED)

32. public class MyBean extends MySuper implements MyI {

33. public void foo() {}

34. @TransactionAttribute(TransactionAttributeType.SUPPORTS)

35. public void bar() {}

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?

A REQUIRED, SUPPORTS, REQUIRES_NEW

B NOT_SUPPORTED, SUPPORTS, REQUIRES_NEW

C NOT_SUPPORTED, SUPPORTS, NOT_SUPPORTED

D REQUIRES_NEW, SUPPORTS, REQUIRES_NEW

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.


Which statements about transaction attributes and propagation is correct?

A A message-driven bean's listener methods can only have a REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED transaction attribute.

B An enterprise bean's timeout callback method can only have a REQUIRED, REQUIRES_NEW, or NOT_SUPPORTED transaction attribute.

C An enterprise bean implementing the javax.ejb.SessionSynchronization interface can only have a REQUIRES or REQUIRES_NEW transaction attribute.

D A session bean's business method cannot have a MANDATORY transaction attribute.

Reference

See 13.3.7 where these are explicitly listed.

Option A is incorrect. It cannot have REQUIRES_NEW.

Option B is correct.

Option C is incorrect. It can have MANDATORY too.

Option D is incorrect. There is no restriction on having a MANDATORY attribute.


Given an excerpt from the implementation of a session bean:

10. @Stateful

11. @TransactionAttribute(TransactionAttributeType.REQUIRED)

12. public class GenomeBean implements Me {

13. @TransactionAttribute(TransactionAttributeType.MANDATORY)

14. public void chromosome(String x) {}

15. public void chromosome(String x, String y) {}

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?

A chromosome(String x) will have a MANDATORY and chromosome(String x, String y) a REQUIRED transactional type.

B chromosome(String x) will have a MANDATORY and chromosome(String x, String y) a MANDATORY transactional type.

C chromosome(String x) will have a SUPPORTS and chromosome(String x, String y) a REQUIRES_NEW transactional type.

D chromosome(String x) will have a SUPPORTS and chromosome(String x, String y) a SUPPORTS transactional type.

E chromosome(String x) will have a SUPPORTS and chromosome(String x, String y) a MANDATORY transactional type.

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.


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. @Remove

17. public void inc() {}

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:


21. public String doIt() {

22. ms.inc();

23. }

The method doIt is called without a transactional context.

Which order properly reflects the order of method invocation?

A doIt, afterBegin, inc

B doIt, inc, afterBegin, beforeCompletion

C doIt, inc, beforeCompletion, afterBegin, afterCompletion

D doIt, inc, afterBegin, beforeCompletion, afterCompletion

E doIt, afterBegin, inc, beforeCompletion, afterCompletion

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?

A AroundInvoke methods cannot throw arbitrary system exceptions.

B AroundInvoke methods should NOT suppress exceptions.

C AroundInvoke methods can throw an arbitrary checked exception.

D If a system exception escapes the interceptor chain of AroundInvoke methods, the bean instance is discarded.

Reference See 12.3.2 of the Core Specification for all of these.

Option A is incorrect because they can throw runtime exceptions.

Option B is incorrect because they can suppress exceptions.

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.


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.

Option D is an instance of java.lang.Exception and so is considered an application exception (See 14.1.1). This causes a rollback.


Given some code from a stateful session bean:

10. @Stateful


12. public class USBean implements US {

13. @PreDestroy

14. public void slashstar() {}

15. public void oops() {

16. throw new javax.persistence.PersistenceException();

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?

A The exception is rethrown.

B An EJBException is thrown by the container to the client.

C It discards the instance of the session bean.

D It performs some actions and eventually executes the slashstar method.

E It is the responsibility of the bean provider to properly catch and handle such exceptions.

Reference See Table 14 in 14.3.1 of the Core Specification. According to this:

Option C is correct. The bean will be discarded.

Option A is incorrect. It will NOT because it is NOT an application exception.

Option B is incorrect. It actually throws a TransactionRolledbackException.

Option D is incorrect. PreDestroy methods are not executed. (See Note C in that table and other places in the Specification.)

Option E is incorrect. There is no such requirement put on bean providers.


Given an interface:

4. @Local

5. public interface MyI {

6. public Set go(Set s);

7. }

Given an excerpt from a stateful session bean that implements this business interface:

9. @Stateful


11. public class MyStatefulBean implements MyI {


13. public Set go(Set s) {

14. ctx.getRollbackOnly();

15. ctx.getEJBOjbect();

16. ctx.getEJBHome();

17. throw new Exception("Will I, won't I?");

18. }

50. }

No deployment descriptor is used.


A An exception is thrown on line 14.

B An exception is thrown on line 15.

C An exception is thrown on line 16.

D An exception is thrown on line 17.

Reference

See Core Specification 4.4.1.

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.


A client, executing in the context of a transaction, makes a call to a session bean and receives a java.rmi.RemoteException.


A The business method has NOT completed.

B The business method has completed, but there was a communication problem after completion.

C The client's transaction might have been marked for rollback.

D The client never receives such an exception. It is always wrapped in another transaction type.

Reference See 14.4.2 for the rules about this.

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.

Option C is correct. It might have.

Option D is incorrect. It can, of course, receive a RemoteException.

Location: ... > Section 11: Security Management > Objective 11.1 > Question 58

Given an excerpt from a stateless session bean:

10. @Stateless

11. @RolesAllowed("JAMES")

12. public class YourBean implements MyI {

13. @DenyAll

14. public void spy() { /* ... */}

15. public void eye() { /* ... */ }

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?

A JAMES can access spy and eye.

B BOND can access spy and eye.

C JAMES and BOND can access spy and eye.

D JAMES can access eye, and BOND can access spy.

E JAMES can access eye, no role can access spy.

F BOND can access eye, no role can access spy.

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.


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

D EJB Server Provider

E EJB Container Provider

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.


Assume ctx is a context object injected into a bean (SessionContext for session beans, EntityContext for entities).

Which business methods throw an exception if a call is made to ctx.getCallerPrinciple()?

A In a business method of a stateless session bean.

B In a PostConstruct annotated method of a stateful session bean.

C In an ejbTimeout method of an entity bean.

D In a PreDestroy annotated method of a stateless session bean.

Reference 17.2.5 of the Core Specification states that an exception is thrown if used in an illegal context.

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.)


Given an excerpt from a descriptor for a stateless session bean:

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 C is correct. (See 17.2.5.3 of the Core Specification.)

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.)

scbcd-5 q&a with explanations - 2

Documents