Scbcd-5 Q&a With Explanations - 1

QUESTIONS FOR SCBCD 5.0 FORM 1 Location: > Section 1: EJB 3.0 Overview > Objective 1.1 > Question 1

Which statement correctly identifies the goals of the designers of the EJB architecture? A The EJB architecture requires that users be aware of the low-level transaction details of the Java EE platform. B The EJB architecture is the standard component architecture for building distributed business applications in the Java programming language. C Although the EJB architecture defines the contracts that enable tools to develop and deploy components, each application server vendor needs to produce its own set of additional tooling. D The EJB architecture provides a standard way of persisting state data using the Java Persistence API, Java Data Objects, and JDBC. Reference Option B is correct. See section 2.1 "Overall Goals" in the Core Specification. None of the other options are listed as goals here. Option A is incorrect because the specification makes it clear that these low-level details are not required. Option C is incorrect because the developer does NOT need tooling from a particular application server vendor. Option D is incorrect because the EJB architecture only standardizes on the Java Persistence API

Location: > Section 1: EJB 3.0 Overview > Objective 1.2 > Question 2

Which two APIs can be used to implement an EJB? (Choose two.) A EJB 2.1 APIs B EJB 3.0 APIs C HTTP Servlet APIs D File I/O APIs E APIs for thread management Reference Options A and B are correct. (See 2.2 of the Simplifies Specification.) Option C is incorrect because servlets are not used to implement enterprise beans. They can be clients of beans, but they are NOT used in the implementation. Options D and E are incorrect because the developer should NOT use thread management/file I/O APIs. (See 21.1.2 of the Core Specification.)

Location: > Section 1: EJB 3.0 Overview > Objective 1.3 > Question 3

What programming restrictions are defined in the EJB specification? A An enterprise bean must NOT use the java.io package to attempt to access files and directories. B A session bean must implement the javax.ejb.SessionBean interface. C An enterprise bean must NOT declare any static fields. D An entity bean class must be NOT be defined as public. Reference Option A is correct. (See 21.1.2 of the Core Specification.) Option B is incorrect because the developer does NOT have to implement it. (See 4.6.2 of the Core Specification.) Option C is incorrect because it can use static fields as long as they are read only. (See 21.1.2 Core Specification.) Option D is incorrect because it must be public (See 10.2.2 of the Core Specification.)

Location: > Section 1: EJB 3.0 Overview > Objective 1.4 > Question 4

The developer has been supplied with an ejb-jar file and now need to have this ejb-jar integrated and deployed as part of a larger application. Which two roles, defined by the EJB architecture, would play a part in this process? (Choose two.) A Enterprise Bean Provider B Application Assembler C Deployer D EJB Server Provider E System Administrator Reference Options B and C are correct. See Core Specification 2.2. The assembler is responsible for combining enterprise beans and the deployer for deploying them. Option A is incorrect because the developer is provided with the ejb-jar file. Enterprise Bean Providers provide enterprise beans. Option D is incorrect because this refers to (typically) an OS vendor or middleware vendor. Option E is incorrect because this role refers to someone who configures the enterprises computing and network infrastructure.

Location:> Section 1: EJB 3.0 Overview > Objective 1.5 > Question 5

An Application Assembler wants to create an enterprise application archive file that contains two ejb-jar files (ejb-jar1 and ejb-jar2). ejb-jar2 makes calls to the enterprise bean in ejb-jar1. ejb-jar1 has an ejbclient-jar, myclient1-jar. What is an appropriate way of packaging these assets into an enterprise application archive? A There are too many dependencies, and the developer cannot create an archive with these requirements. B Package all three jar files in the archive, with appropriate metadata to link them. C Package myclient1-jar as part of ejb-jar1, and ejb-jar1 and ejb-jar2 in the enterprise application archive. D Package ejb-jar1 as part of myclient1-jar, and the resulting myclient1-jar together with ejb-jar2 in the enterprise application archive. Reference Option B is correct. See Chapter 20 in the Core Specification. In particular 20.4, 20.5 and 20.6. Option A is incorrect because B is correct. Option C is incorrect because ejb-jar2 needs to call ejb-jar1 and needs access to the client classes. Option D is incorrect because the developer does NOT package ejb-jar files as part of a client jar. Location: > Section 1: EJB 3.0 Overview > Objective 1.6 > Question 6

Which statement is an accurate description of how annotation metadata and descriptor metadata are to be used together? A Deployment descriptor metadata can only be used to modify annotation metadata. B A deployment exception is thrown if deployment descriptor metadata and annotation metadata describe the same class, method, or field. C Metadata annotations can be used as an alternative to deployment descriptors in most cases. D Annotation metadata can only be used to modify deployment descriptor metadata. Reference Option C is the only accurate description. See the Simplified Specification 2.1. Option D and A are incorrect because there is no requirement that only one set of metadata must be used to modify the other. Option B is incorrect because there is no requirement that the two types of metadata are independent. They can both describe the same item.

Location: > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.1 > Question 7

Which two statements correctly identify when life-cycle callback methods on enterprise beans can be used? (Choose two.) A Stateful session beans support the PostConstruct, PreDestroy, PostActivate and PrePassivate lifecycle callbacks. B Message-driven beans support the PostConstruct, PreDestroy, PostActivate and PrePassivate lifecycle callbacks. C Stateless session beans support the PostConstruct and PreDestroy life-cycle callbacks. D Entities support the PostConstruct and PreDestroy callbacks. E Stateless session beans support the PostActivate and PrePassivate life-cycle callbacks. Reference Option A is correct. See Simplified 5.1.4. Option B is incorrect because message-driven beans only support PostConstruct/PreDestroy (See Simplified 6.1.3.) Option C is correct. See Simplified 4.1.4. Option D is incorrect. See Persistence 3.5.1. Option E is incorrect. See 4.1.4. Location: > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.2 > Question 8

Given the following session bean: 10. @Stateless 11. @Interceptors(MyOtherInterceptor.class) 12. public class MyBean ... { 13. 14. @ExcludeDefaultInterceptors 15. @Interceptors(MyInterceptor.class) 16. public void someMethod() { 17. } 18. }

Assume that no descriptors are used. Which interceptor classes are called when someMethod() executes? A No interceptor classes are called. B MyInterceptor. C MyOtherInterceptor. D MyOtherInterceptor and MyInterceptor. Reference Option D is correct, see 12.7 in Core Specification. The ExcludeClassInterceptors annotation was not used, but ExcludeDefaultInterceptors, which in this case does nothing because there is nothing in the descriptors. Options A, B, and C are incorrect. Both classes are called, as described in Option D. Location: > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.3 > Question 9

Given the following code snippet taken from a stateless session bean CrumbleBean: 1. package apple; 2. // .. 10. @Stateless public class CrumbleBean implements Crumblee { 11. @Resource int dough; 12. //... 20. } What JNDI name must correspond with the field named dough? A dough B java:comp/env/apple.CrumbleBean/dough C apple.CrumbleBean/dough D java:apple.CrumbleBean/dough Reference Option B is correct. See 16.2.2 of Core Specification., first bullet. Remember these environment resources are located in the java:com/env space. Options A,C,D are incorrect because B is correct, per the specification.

Location: > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.4 > Question 10

Given the following excerpt from a stateless session bean: 10. @Stateless 11. public class OvenBean implement Oven { 12. @Resource SessionContext ejbContext; 13. @Timeout 14. @TransactionAttribute(REQUIRED) 15. public void ping(javax.ejb.Timer timer) { 16.

// line 16

17.

ejbContext.setRollbackOnly();

18. } 19. // .. more methods here .. 99. } Assume that a timer is set up and initiated for this bean. What happens when the timer expires (that is, after the time specified elapses)? A Nothing happens. B The method ping is called only once. C The method ping is called at least twice. D An exception is thrown because of the transactional attribute set on the method Reference Option C is correct. The method ping, which is set up as a valid time out method because of the @Timeout annotation, is called at least twice and is valid with a REQUIRED transaction attribute. It is called once, when the time expires. The container then rolls back the transaction (because of the call to setRollbackOnly), rescinding the timeout. It is called at least once more (and is, when run on Glassfish) according to the Core Specification 18.4.2. Option B is incorrect because the specification states that the container should retry the timeout. Options A and D are incorrect because the code is valid and executes correctly.

Location: > Section 2: General EJB 3.0 Enterprise Bean Knowledge > Objective 2.5 > Question 11

Given the following session bean: 10. @Stateless 11. public class OvenBean implements Oven { 12. @Resource SessionContext ctx; 13. public void heat() { 14.

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

15.

Collection c = t.getTimers();

16.

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

17. } 18. @Timeout 19. void foo(Timer t) { 20.

ctx.lookup("HiThere");

21. } 22. // more methods here 99. } Here, the method heat is a business method of the bean. A remote client invokes the heat method of an instance of this bean. What happens when this method is invoked? A An exception is raised on line 19, some time after the heat method is invoked. B An exception is raised on line 14. C The method returns, and some time later foo is invoked because of the timeout. D An exception is raised on line 16 because this is NOT a valid use of the timer service. E An exception is raised on line 15. Reference Option B is correct. This code uses the SessionContext.lookup method, not a lookup on an InitialContext. As such, it does NOT find the timer service here. Option A is incorrect. The ctx variable is initialized. The lookup returns null. Of course, this method never gets invoked though because of B. Options C, D and E are incorrect. If t was bound to a valid TimerService instance, it would be fine. Passing in this would be fine too, because the bean implements Serializable. (See 18.2.1 of the Core Specification)

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 interoperability is correct? A A client of a stateless session bean written to the new EJB 3.0 API cannot be a client to a stateless session bean written to the EBJ 2.1 API. B EJB clients can access only EJB 3.0 entities and EBJ 2.0 entity beans together if transactions are NOT used. C A client of a stateful session bean written to the new EJB 3.0 API cannot be a client to a stateful session bean written to the EBJ 2.1 API. D Existing EJB 2.1 beans must be supported to run unchanged in EJB 3.0 containers. Reference Option A is incorrect. It can be a client of an EJB 2.1 component. See 9.2.2 of the Simplified Specification. Option B is incorrect. You can use transactions. See 9.2.3 of the Simplified Specification. Option C is incorrect. It can be a client of an EJB 2.1 component. See 9.2.2 of the Simplified Specification. Option D is correct. See 9.1 of the Simplified Specification. Location: > Objective 3.1 > Question 13

Which statement characterizes stateless session beans? A They allow the PostActivate, PostConstruct and PreDestroy life-cycle callbacks B They require home interfaces. C Stateless session beans typically execute on behalf a single client. D They are asynchronous message consumers. Reference Option A is incorrect. The developer cannot use PostActivate on a stateless bean. (See 4.1.4 of the Simplified Specification.) Option B is incorrect. Session beans do NOT require home interfaces. (See the Simplified Specification 3.5.) Option C is correct. (See 2.4.1 of the Core Specification.) Option D is incorrect. Message-Driven beans are asynchronous message consumers. (See 2.4.2 of the Core Specification.)

Location: > Objective 3.2 > Question 14

A business interface for a stateful session bean is defined as follows: 5. public interface MyI { 6. public Set go(Set s); 7. } Given an excerpt from a stateful session bean that implements this business interface: 10. @Stateful 11. public class MyStatefulBean implements MyI { 12. public Set go(Set s) { 13.

s.add("Goodbye");

14.

return s;

15. } 50. } No deployment descriptors are used. A client has a reference to an instance of this stateful bean in the variable foo, and executes the following code: 60. Set s = new HashSet(); 61. s.add("Hello"); 62. foo.go(s); 63. s.add("Gut"); What is the value of the set s after this code has executed (at the end of line 63)? A "Hello" B "Hello" and "Gut" C "Hello" and "Goodbye" and "Gut" D "Goodbye" and "Gut" Reference Option C is correct. MyI is actually a local interface because no explicit @Local or @Remote annotation is present, and its the only interface implemented by the bean. (See 3.2 of the Simplified Specification.) As a result, pass-by-reference semantics are used (See 3.2.2 of the Core Specification). Consequently, all values are added to the same set, and so C is correct. Options A, B, D are incorrect because C is correct.

Location: > Objective 3.3 > Question 15

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

Reference Option A is correct, it is a fault. The programmer cannot implement SessionSynchronization in a stateless bean, only in a stateful one. (See 4.5 of the Core Specification.) Option C is correct, it is a fault. The programmer should NOT implement the finalize method (See 4.6.2 of the Core Specification.) For the incorrect answers, Option B is NOT a fault. There is nothing wrong with this resource declaration. Option D is NOT a fault either. There is nothing wrong with having a Socket here (there are items that the developer cannot do with it though, see 21.1.2 of the EJB Core Specification). Finally, Option E is NOT a fault. There is nothing wrong with having a helper method defined. (See 4.6.2 of the Core Specification.) Location: > Objective 3.4 > Question 16

A stateful session bean can receive a number of life-cycle callbacks during its lifetime. Which order is a valid reflection of the order of life-cycle callbacks for a single stateful session bean? A PreDestroy, PreActivate, PostActivate, PostConstruct B PrePassivate, PostConstruct, PostActivate C PostConstruct, PrePassivate, PostActivate, PreDestroy D PostConstruct, PostActivate, PrePassivate, PreDestroy Reference Option A is incorrect because the developer cannot do anything much until after PostConstruct. The developer certainly cannot destroy/passivate the bean before it is constructed. (See 4.4 of the Core Specification.) Option B is incorrect because the developer cannot do anything until after PostConstruct. The developer certainly cannot passivate the bean before it is constructed. (See 4.4 of the Core Specification.) Option C is a correct order. (See 4.4 of the Core Specification.) Option D is incorrect because it cannot PostActivate before a PrePassivate. (See 4.4 of the Core Specification.)

Location :> Objective 3.5 > Question 17

A stateful session bean contains the following business method: 9. @WebMethod 10. public void resetVal(String value) { 11. Context ctx = new InitialContext(); 12. String oldVal = (String) ctx.lookup("java:comp/env/val"); 13. ctx.rebind("java:comp/env/val", value); 14. } What happens when this method executes? A The old value for val in the environment context is replaced with the new value. B The old value is NOT changed and the method simply exits without normally. C A javax.naming.OperationNotSupported exception is generated. D An exception is raised on line 11 when a new context is created. Reference Option C is correct because session beans only have read-only access to their environment. All the other options are incorrect because of this. (See 16.4.4 of the Core Specification.)

Location: > Objective 3.6 > Question 18

Which statement about exposing session beans as web services is correct? A The methods in a session bean exposed as web service operations should declare the methods to throw java.rmi.RemoteException. B If a bean implements a web service, it must explicitly define a web service interface. C Methods of a session bean exposed in a web service can be transactional. D Methods of a session bean exposed in a web service cannot have method permissions set. Reference Option A is incorrect. They should NOT. (See the Simplified Specification 3.3.) Option B is incorrect. It does NOT have to. It can use @WebMethod instead. (See 4.1.1 of the Simplified Specification.) Option C is correct. See 13.3.6 of the Core Specification.) Option D is incorrect. They can. (See 17.3.2 of the Core Specification.)

Location: > Objective 3.7 > Question 19

A client tests two stateful session bean business interface references for identity using the equals method as follows: 10. @EJB Sfb fee; 11. @EJB Sfb fi; 12. if (fee.equals(fee)) { /* some code */ } 13. if (fee.equals(fi)) { /* some code */ } Which statement is true about this testing? A The test on line 12 always succeeds with true, but the test on line 13 always fail with false. B Both tests always succeed with true. C The developer should NOT compare business interface references with the equals method. D The tests on line 12 and 13 both always return false. Reference Option A is correct. Each bean has a unique identify, so 13 fails. (See 3.4.5.1 of the Core Specification.) Option B is incorrect because A is correct (so line 13 will fail) Option C is incorrect because the specification allows such comparison. Option D is incorrect because A is correct (so line 13 will fail).

Location: > Objective 4.1 > Question 20

Given an excerpt from a message-driven bean implementation: @MessageDriven() public class DeliveryBean implements javax.jms.MessageListener, javax.ejb.MessageDrivenBean { public void onMessage(Message msg) { /* ... */} public void setMessageDrivenContext(MessageDrivenContext c) { /* ... */ } public void ejbRemove() { /* ... */ } @PostConstruct public void openDoor() { /* ... */ }

Which statement reflects a valid order of method invocation that the developer could find in the lifetime of an instance of this bean? A onMessage, setMessageDrivenContext, openDoor, ejbRemove B openDoor, setMessageDrivenContext, onMessage, ejbRemove C setMessageDrivenContext, openDoor, onMessage, ejbRemove D setMessageDrivenContext, onMessage, ejbRemove

Reference See 5.4.8 the Core Specification. Option C is correct. All other options are incorrect because C is the correct order. (See 5.4.8 of the Core Specification.)

Location: > Objective 4.2 > Question 21

Which statement is correct about message-driven beans? A Message-driven beans cannot hold state in their instance variables across the handling of multiple client messages. B References to message destinations can be injected, but not looked up in the JNDI namespace. C A message-driven bean does NOT need to implement a message listener interface. D Message-driven beans are anonymous. They have no client-visible identity

Reference Option D is correct. (See 5.1 of the Core Specification.) Option A is incorrect. They can. (See 5.1 of the Core Specification.) Option C is incorrect. It does need to, for the appropriate message type. (See 5.4.2 of the Core Specification.) Option B is incorrect because they can be looked up in JNDI. (See 5.4 of the Core Specification.)

Location: > Objective 4.3 > Question 22

Which statement is correct about the delivery of messages to a message-driven bean? A Message-driven beans should be coded to be reentrant. B The container serializes all calls to a message-driven bean instance, including message listener calls and any callbacks. C The container only allows a single instance of a message-driven bean of any one type to be executing, and serializes any additional incoming messages to this instance. D All messages are delivered to message-driven beans in the same order in which they are sent.

Reference Option A is incorrect. They do NOT because the container serializes requests. (See 5.4.10 of the Core Specification.) Option B is correct. (See 5.4.10 of the Core Specification.) Option C is incorrect. A container typically maintains a pool, allowing concurrent execution. (See 5.4.11 of the Core Specification.) Option D is incorrect. No guarantees are made about the order.

Location: > Objective 4.4 > Question 23

Which statement is true about a JMS message-driven bean and its clients, assuming that the messagedriven bean uses container-managed transactions? A Clients can access the message-driven bean through its business interface. B If a client sends a message to a message-queue that has the message-driven bean configured to listen on that queue with an auto-acknowledge mode, then the client must wait for an acknowledgment after sending the message before sending another. C Clients cannot receive exceptions from the message-driven bean. D Message-driven beans are multi-threaded and so can process multiple messages from different clients at the same time.

Reference Option A is incorrect. They do NOT have a business interface. They are decoupled from their clients. (See 5.3 of the Core Specification.) Rather, clients talk to a destination or endpoint, NOT a bean. Option B is incorrect. JMS is asychronous. Option C is correct. They cannot. (See 5.4.17 of the Core Specification.) The container actually takes the bean to a does-not-exist state and assigns other instances to the destination. Option D is incorrect. They are single-threaded and can process only one at a time. A container pools instances of them, allowing concurrent execution. (See 5.4.11 of the Core Specification.) Location: > Section 5: Java Persistence API Entities > Objective 5.1 > Question 24 Which statement about entities is correct? A Entities must be annotated with the @Entity annotation. B Entities can be final classes. C Entities can have a single no-arg constructor with protected visibility. D Instance variables of an entity can have private, protected, public, or package visibility. Reference Option A is incorrect. The developer can use the XML descriptor instead. (See 2.1 of the JPA Specification.) Option B is incorrect. They cannot be final. (See 2.1 of the JPA Specification.) Option C is correct. That no-arg constructor can be protected, it does NOT have to be public. (See 2.1 of the JPA Specification.) Option D is incorrect. They must NOT be public. (See 2.1 of the JPA Specification.)

Location: > Section 5: Java Persistence API Entities > Objective 5.2 > Question 25

Given an excerpt from a simple class: 5. public class Foo implements Serializable { 6. String s; 6. } And given an excerpt from an entity that references this class: 10. @Entity 11. public class Bar { 12.

@Id private Integer id;

13. @Transient Integer moo; 14. @Temporal(TemporalType.DATE) java.sql.Date doo; 15. @Lob @Basic protected Byte[] bits; 16. @Basic(fetch=FetchType.EAGER, optional=true) private Integer goo; 17. transient int soo; 18. /* ... */ 19. } Which line in the Bar class causes this class to NOT be a valid entity class? A 13 B 14 C 15 D 16 E 17

Reference Option B is correct. The @Temporal annotation must be used for java.util.Date/java.util.Calendar only. (See 9.1.20 of the JPA Specification.) Option A and E are incorrect. This is a valid use of @Transient and the transient declaration is fine as well. (See 9.1.16 of the JPA Specification.) Option C is incorrect. This LOB definition is correct. See 9.1.19 of the JPA Specification.) Option D is incorrect. This is a valid use of @Basic. The fetch type is eager by default anyway, and the optional flag is just a hint (defaulting to true also). (See 9.1.18 of the JPA Specification.)

Location: > Section 5: Java Persistence API Entities > Objective 5.3 > Question 26

A Book entity must be mapped to a legacy database that uses multiple columns to represent a primary key for each row. The primary key is composed of two integers. The Book entity has a single persistent field, bookname. Which statement about mapping the primary keys is correct? A The developer can use the @Id annotation on multiple fields to define which fields comprise the composite key. For example, given a complete definition: 10. @Entity public class Book { 11. @Id int id1; 12. @Id int id2; 13. String bookname; 13. } B The developer can properly code an external Id class, say MyId, that holds the primary key values. The entity can then be defined as follows: @Entity @IdClass(MyId.class) public class Book { String bookname; }

C The developer can properly code an external Id class, say MyId, annotated with @Embeddable, that holds the primary key values. The entity can then be defined as follows: @Entity public class Book { String bookname; @EmbeddedId private MyId id; } D When a primary key class is defined to hold a composite key, it need NOT be public but it must have a public no-arg constructor and it must be serializable. Reference See 2.1.4 and 2.1.5 of the JPA Specification. Option A is incorrect. The developer can only use @Id for simple (non-composite) keys. Composite keys cannot be created this way. See 2.1.4 of the JPA Specification. (Unless the developer is using an IdClass, but in that case the developer must supply an IdClass class as well.) Option B is incorrect. The developer needs to mark each field that makes up the IdClass with @Id in the entity. In this case, the entity should have had @Id int id1; @Id int id2; (See 9.1.15 of the JPA Specification.) Option C is correct. This is the correct way to use @EmbeddedId. Option D is incorrect. It must be public, as well having the other attributes (See 2.1.4 of the JPA Specification.) Location: > Section 5: Java Persistence API Entities > Objective 5.4 > Question 27

Given an excerpt from an entity bean Bar, which references another entity bean Foo: 10. @OneToMany(targetEntity=Foo.class) 11. public Collection getFoos() { 12. return foos; 13. } No descriptor files are used.

Which statement is correct? A This is a unidirectional relationship. B This is a bidirectional relationship. C Replacing line 10 with @OneToMany, removing the targetEntity annotation element, changes the behavior of this code. D Additional mapping information is necessary to make this a valid definition. Reference Option A is correct, and Option B is NOT correct. It is unidirectional because if it was bidirectional then the mappedBy attribute must be used in the annotation. (See 9.1.24 of the JPA Specification.) Put another way, if it was bidirectional, then there must be an owning and an inverse side. In a one-to-many relationship, the many side must be the owning side. Because this is the "one" side, not the "many" side (OneToMany), if this was bidirectional, it would have to be the inverse. And an inverse always refers to the owning with a mappedBy. (See 2.1.7 of the JPA Specification.) Because there is no mappedBy, it is not bidirectional. Option C is incorrect. Because this code uses generics on line 11, the annotation element is not even necessary. (See 9.1.24 of the JPA Specification.) Option D is incorrect. No additional mapping information is needed. (See 9.1.24 of the JPA Specification). Location: > Section 5: Java Persistence API Entities > Objective 5.5 > Question 28

A domain model comprises two entities: Flea and Dog. The developer is required to construct these entities so that the Flea and Dog entities are in a unidirectional many-to-one relationship. Which statement about implementing this model is NOT correct? A The @ManyToOne annotation must be placed in the Flea entity. B If a @JoinColumn annotation is used, it must be placed in the Flea entity. C The Dog entity must contain the @OneToMany annotation. D The Flea entity is, by default, mapped to a table containing a foreign key. Reference For an example of this scenario, see 2.1.8.3 and 2.1.8.3.2 of the JPA Specification. Option C is the option that is NOT correct here. Because this is a unidirectional relationship, the OneToMany annotation should NOT be used. All of the other options are correct. That is, the Dog entity does NOT reference the Flea entity, the Flea entity is the owner and as such, contains the foreign key.

Location: > Section 5: Java Persistence API Entities > Objective 5.6 > Question 29

Which statement is correct about mapping hierarchies? A The single-table strategy does NOT support queries that range over the hierarchy very well. B The single-table strategy requires a discriminator column. C The table-per-concrete class strategy provides good support for polymorphic relationships. D If a mapped superclass is at the root of an inheritance hierarchy, it has its own table when this hierarchy is implemented with the joined-subclass strategy where each subclass is mapped to a single table. Reference Option A is incorrect, it does. No joins are necessary. (See 2.1.10.1 of the JPA Specification.) Option B is correct, it does. (See 2.1.10.1 of the JPA Specification.) Option C is incorrect. It does not, because it requires expensive SQL UNIONs. (See 2.1.10.2 of the JPA Specification.) Option E is incorrect. Mapped superclasses are NOT entities, but a way to share persistent entity state and mapping information. (See 2.1.9.2 of the JPA Specification.) Location: > Section 5: Java Persistence API Entities > Objective 1.7 > Question 30

Given the definition for a mapped superclass: 5. @MappedSuperclass 6. public abstract class Tome { 7. int papyrus; 8. } and given the definition for an entity that uses it: 11. @Entity 12. public class Book extends Tome { 13. @Id Integer id; 14. @Column(name="NAMEBOOK") 15. String bookName; 16. }

The associated descriptor file has the following snippet pertaining to this entity: 21. <entity class="Book"> 22. 23.



24.



25.



26.



27.



28.



29.



30. No other parts of the deployment descriptor affect this configuration. Which statement is correct? A The descriptor and metadata excerpts given above result in an undefined behavior. B The Book entity is mapped to the BOOK table, with its bookName field mapped to TOMENAME in this table. The papyrus field is mapped to the column EBOOK in the BOOK table. C The Book entity is mapped to the BOOK table, with its bookName field mapped to TOMENAME in this table. The papyrus field is mapped to the column EBOOK in the TOME table. D The Book entity is mapped to the BOOK table, with its bookName field mapped to NAMEBOOK in this table. The papyrus field is mapped to the column EBOOK in the BOOK table. E The Book entity is mapped to the BOOK table, with its bookName field mapped to NAMEBOOK in this table. The papyrus field is mapped to the column EBOOK in the TOME table. Reference Option B is correct. By default, the Book entity is mapped to the Book table. (See 9.1.1 of the JPA Specification.) A mapped superclass is NOT mapped to a different table, because its state is part of the BOOK table. So this makes Option C and Option E incorrect. Line 14 maps the bookName field to NAMEBOOK, but line 26 overwrites this to TOMENAME. (See 10.1.4.10 of the JPA Specification). So Option D is incorrect. Finally, the attribute-override annotation ensures that the papyrus field is mapped to EBOOK. (See 10.1.3.13 and 9.1.10 of the JPA Specification). The descriptor and metadata excerpts are fine - no conflicting undefined behavior results, making Option A incorrect.

Location: > Section 6: Java Persistence Entity Operations > Objective 6.1 > Question 31

Given an excerpt from a stateless session bean that is manipulating entities through the entity manager assigned to the variable em. The method executes within a REQUIRES_NEW transactional context: 10. public void deWorm(int personId) { 11. Person p = em.find(Person.class, Integer.valueOf(personId)); 12. em.remove(b); 13. em.remove(b); 14. } The Person entity is in a one-to-one relationship with a Car entity. A client calls the method deWorm with a personId corresponding to an existing Person entity in the database. Which statement about the behavior of entity removal is correct? A The entity is removed from the database before line 13 is reached. B A related Person entity is removed only if the relationship is annotated with cascade=ALL (assuming no descriptors are used). C Lines 11 to 13 represent an incorrect use of the find or remove methods on the EntityManager interface. D An exception is NOT thrown on line 13 Reference Option D is correct. No exception is thrown. It is valid to call remove on a removed entity. The semantics is that the second remove is ignored. (See 3.2.2 of the JPA Specification.) Option A is incorrect. A developer cannot say it will be removed (from the database, as the question states) at this point. The specification (3.2.2 of the JPA Specification) says that it will happen "at or before transaction commit or as a result of the flush operation." Option B is incorrect. It can be annotated with cascade=REMOVE. (See 3.2.2 of the JPA Specification.) Option C is incorrect. This is the correct use of the interface.

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? A Entities in the managed or detached states have a persistent identity, while those in the new and removed states do NOT. B If an entity in the managed state is persisted again, the persist operation is ignored, but cascaded to the appropriate relationships referenced by the entity. C Persisting an entity in the removed state causes an exception to be thrown. D Persisting an entity in the detached state moves it to the managed state. Reference Option A is incorrect. Those in the removed state have a persistent identity. (See 3.2 of the JPA Specification.) Option B is correct. (See 3.2.1 of the JPA Specification.) The cascade still works when the developer persists a managed entity. Option C is incorrect. It does NOT cause an exception. It does cause the entity to become managed. (See 3.2.1 of the JPA Specification.) Option D incorrect. An exception is thrown. (See 3.2.1 of the JPA Specification.)

Location: > Section 6: Java Persistence Entity Operations > Objective 6.3 > Question 33

Assume Book is an entity and em is bound to an entity manager. Which statement is correct about merging detached entity state? A All persistent fields of an entity are used in a merge. B Some time after the following code is executed: Book flashy= new Book("Flashman"); em.merge(flashy); the object bound to the variable flashy becomes managed. C If the developer attempts to merge a detached Book entity with an entity manager that is NOT currently managing an entity with the same identity, an exception is generated. D Merging an entity in the removed state results in either an exception or a transaction commit fail.

Reference Option A is incorrect. Persistence providers actually ignore fields that are marked as LAZY if they have NOT been fetched. If they have been fetched, they are used. (See 3.2.4.1 of the JPA Specification.) Option B is incorrect. It will NOT be managed. The object returned by merge is managed (discarded in this example) as the state (of flashy) is actually copied into a new instance that becomes merged. (See 3.2.4.1 of the JPA Specification.) Option C is incorrect. You can merge any kind of detached entity, regardless of whether it is currently managed. (See the first bullet point in 3.2.4.1 of the JPA Specification.) Option D is correct. The developer cannot merge removed entities. (See 3.2.4.1 of the JPA Specification.)

Location: > Section 6: Java Persistence Entity Operations > Objective 6.4 > Question 34

Given the following entity definition: 10. public class Book extends BookSuperDuper { 12. @Id public Integer id; 13. 14. public void prepersist() { 15. 16. } This uses the following class: 20. @MappedSuperclass 21. public abstract class BookSuperDuper { 22. @PrePersist 23. public void prepersist() { 24. System.err.println("--- @PrePersist in BookSuperDuper---"); 25. } 26. }

}

No descriptors or other metadata are used. Which method is called when an instance of Book is successfully persisted? A Neither the prepersist method in Book nor the prepersist method in BookSuperDuper is called. B Only the prepersist method in Book is called. C Only the prepersist method in BookSuperDuper is called. D The perpersist method in Book is called, followed by the prepersist method in BookSuperDuper. E The perpersist method in BookSuperDuper is called, followed by the prepersist method in Book. Reference Option C is correct. (See 3.5 of the JPA Specification.) A life-cycle callback method can be defined on a mapped superclass, as has been done here. According to section 3.5.4 of the JPA Specification, you can override it as well. Ordinarily, this would NOT cause the overridden method to be invoked, but in the example case, there is no @PrePersist annotation on line 13. So the overridden method is invoked. See the footnote in this section. Options A, B, D, and E are incorrect because Option C is the correct order. Location: > Section 6: Java Persistence Entity Operations > Objective 1.5 > Question 35

Which statement about versioning is correct? A Version-locking fields defined in an entity can be only of type int, Integer, short, Short, long, or Long. B The following is a valid declaration of a version property: 10. @Version 11. @Column(name="oof") C An entity cannot expose a method that returns the version number to clients of that entity. D An entity that has a version attribute cannot be in a relationship with an entity that does NOT have a version attribute (assuming no configuration files are used). Reference Option A is incorrect. They can be of type java.sql.Timestamp too. (See 9.1.17 of the JPA Specification.) Option B is correct. See section 9.1.17 of the JPA Specification for the definition of this annotation. Option C in incorrect. It is correct to provide (read) access to the version. (See 3.4.2 of the JPA Specification.) Option D is incorrect. The developer can mix entities that support and do NOT support optimistic locking. (See 3.4.2 of the JPA Specification.)

Location: > Section 7: Persistence Units and Persistence Contexts > Objective 7.1 > Question 36

Which statement about JTA and resource-local entity managers is correct? A The default transaction type for an entity manager is JTA in both Java EE and Java SE environments. B The developer cannot use a resource-local entity manager in a Java EE environment. C The EntityTransaction interface must be used when using a resource-local entity manager. D Application-managed entity managers can be only of JTA transaction type. Reference Option A is incorrect. The default is resource-local for Java SE. (See 6.2.1.2 of the JPA Specification.) Option B is incorrect. The developer can. (See 6.2.1.2 of the JPA Specification for an example.) Option C is correct. The developer needs to use this to explicitly start/commit the transactions. (See 5.5.2 and 5.5.2.1 of the JPA Specification.) Option D is incorrect. They can be resource-local as well. (See 5.5 of the JPA Specification.) Location: > Section 7: Persistence Units and Persistence Contexts > Objective 7.2 > Question 37

Which statement about container-managed persistence contexts is correct? A A stateless session bean can create and use a container-managed extended persistence context. B A transaction-scoped container-managed persistence context can be used only in a stateful session bean. C The lifetime of an transaction-scoped container-managed persistence context associated with a session bean lasts only as long as the method using the context. D When container-managed entity managers are used, the application does NOT interact with the entity manager factory.

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

Location: > Section 7: Persistence Units and Persistence Contexts > Objective 7.3 > Question 38

Which statement about application-managed persistence contexts is correct? A Application-managed persistence contexts must always be extended in scope, and cannot be transaction-scoped. B A developer can use methods on the EntityManagerFactory API to join or retrieve a transaction. C Application-managed persistence contexts are supported in Java SE environments only; NOT Java EE environments. D Application-managed persistence contexts cannot use a resource-local transactional type. Reference Option A is correct. (See 5.7 of the JPA Specification.) Option B is incorrect. The developer uses methods on the EntityManager API. (See 5.7 of the JPA Specification for an example.) The EntityManagerFactory only has methods to create, check whether one is open, and close an entity manager. Option C is incorrect. They can be used in Java EE environments also. (See 5.1 of the JPA Specification.) Option D is incorrect. It can be resource-local or JTA. (See 5.5 of the JPA Specification.) Location: > Section 7: Persistence Units and Persistence Contexts > Objective 7.4 > Question 39

Given an excerpt from a stateful session bean: 09. @Stateful 10. public class MyBean implements MyiMy { 11. @PersistenceUnit(unitName="MyService") 12. EntityManagerFactory emf; 13. EntityManager em; 14. @PostConstruct 15. public void init() { 16.

em = emf.createEntityManager();

17. } 18. public void checkoutBook(int bookId) { 19.

em.joinTransaction();

20.

Book b = em.find(Book.class, bookId);

21.

b.setCheckedOut(true);

22. }

23. } The MyService persistence unit has been configured so that the entity managers provided by the entity manager factory are JTA entity managers. The Book entity exists. Moreover, checkoutBook and init are business methods declared in MyiMy. Which statement is true, assuming no passivation occurs? A If a JTA transaction is NOT active, line 19 does nothing. B If a JTA transaction is active, line 19 ensures that the entity manager joins the transaction; but only if the transaction was created in a bean-managed transactional component. C The annotation on line 11 and the workings of the init method do NOT reflect how an entity manager should be created. D This code work just fine when called from a stateful session bean method with a REQUIRES_NEW transaction attribute. Reference Option A is incorrect. A JTA transaction must be active, otherwise, an exception is thrown. (See 3.1.1 of the JPA Specification API documentation for this method.) Option B is incorrect. It does NOT matter how a JTA transaction is created: bean-managed or containermanaged are both fine. Option C is incorrect. This code is fine. (See 5.7 and 5.7.1.1 of the JPA Specification.) Option D is correct. As long as a JTA transaction is in place, this code is fine. (See 5.7 and 5.7.1.1 of the JPA Specification.) Location: > Section 7: Persistence Units and Persistence Contexts > Objective 7.5 > Question 40

An application, APP, is deployed as an EAR. The library directory of the EAR contains a jar file, foo.jar. The foo.jar file contains a persistence.xml and plattegrond.xml file located in its META-INF directory and persistence classes. No other files within the EAR contain persistence classes or a persistence.xml file. Given an excerpt from the persistence.xml file: 10. 11. <mapping-file>META-INF/plattegrond.xml 12. Which statement is correct? A No persistence unit is defined at all because this is NOT a valid location for a persistence unit to be defined. B The mapping metadata is only ever gathered from persistence.xml only. C The mapping metadata is only ever gathered from persistence.xml and the persistence classes only.

D The mapping metadata is only ever gathered from persistence.xml and the persistence classes and plattegrond.xml only. E The mapping metadata is only ever gathered from persistence.xml, orm.xml if it exists, and the persistence classes and plattegrond.xml only. Reference Option A is incorrect. It is valid to put it in a jar file in the library of an EAR. (See 6.2 of the JPA Specification.) Option B is incorrect. plattegrond.xml is also used. Option C is incorrect. plattegrond.xml is also used. Option D is incorrect. orm.xml is used as well, if it exists. Option E is correct. (See 6.2.1.6 and 6.2.1.8 of the JPA Specification.)

Location: > Section 8: Java Persistence Query Language > Objective 8.1 > Question 42

Given an excerpt from an entity: 10. @Entity 11. public class Koala { 12. int children; 13. @Id 14. private Integer id; 15. /* ... */ 16. } The following code was written to find the maximum and average number of children across all Koala entities: 20. String query = "SELECT max(k.children), AVG(k.children) from Koala k"; 21. Query q = em.createQuery(query); 22. Object[] o = (Object []) q.getSingleResult(); Which two statements are correct? (Choose two.) A There is a syntax error in the JPQL on line 20. B If the variable o is NOT null, the types of the two values in the array are Integer and Double respectively. C There is an error in the typecasting on line 22, which results in a runtime or compile-time exception.

D If the variable o is NOT null, the types of the two values in the array are Double and Double respectively. E The syntax of the JPQL statement on line 20 is valid and the code executes without an error. F A runtime exception is generated on line 22. Reference Option E and Option B are correct. This is a valid JPQL query. (See 4.8.4 of the JPA Specification.) The type of the return value is (Object[]) (See 3.6.1 of the JPA Specification) and in this case the MAX aggregate function returns Integer and AVG a Double (See 4.8.4 of the JPA Specification.) Options A, C, D, and F are incorrect because there is no syntax error in the query or the code. Location: > Section 8: Java Persistence Query Language > Objective 8.2 > Question 43

A Leopard entity is in a one-to-many relationship with a Spot entity. Given an excerpt from the Leopard entity denoting this: 10. @OneToMany(mappedBy="spoton", fetch=FetchType.LAZY) 11. Collection<Spot> spots; A developer wants to ensure that whenever Leopard entities are retrieved, the associated Spot entities are also retrieved. The query must return all Leopard instances, regardless of whether they have Spot instances. Which query accomplishes this? A SELECT l FROM Leopard l B SELECT l FROM Leopard l INNER JOIN FETCH l.spots C SELECT l FROM Leopard l OUTER JOIN FETCH l.spots D SELECT l,s FROM Leopard l LEFT JOIN FETCH l.spots s E SELECT l FROM Leopard l LEFT OUTER JOIN FETCH l.spots Reference Option E is correct. (See 4.4.5.3 of the JPA Specification.) Option A is incorrect because the fetch type is lazy Option B is incorrect because it does an inner instead of an outer join and the question asks for "regardless of whether Spot instances are there." Option C is incorrect because the syntax is wrong. The developer cannot have "OUTER JOIN FETCH" only "LEFT JOIN FETCH" or "LEFT OUTER JOIN FETCH." Option D is incorrect because you are NOT allowed to name the fetch ("s" is not allowed).

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 bidirectional relationship with a Pen entity. In other words, User.pens is the collection of pens for a User, while Pen.owner is the User entity owning that Pen. A developer wants to select only User entities that have at least one associated Pen entity. The developer writes the following query, which does the job: SELECT u from User u WHERE EXISTS (SELECT b from u.books b) Which query returns the same set of results when there are Book and Pen entities in the database? A SELECT u from User u WHERE COUNT(u.books) > 0 B SELECT u from User u WHERE EXISTS (SELECT b from Book b where b.owner = u) C SELECT u from User u WHERE ANY(u.books) D SELECT u from User u WHERE NOT SOME(u.books) Reference Option A is incorrect. COUNT cannot be used like this, but SIZE can. (See 4.6.16.2 of the JPA Specification.) Option B is correct. EXISTS takes a subquery, and the one given here is valid. (See 4.6.13 of the JPA Specification.) Option C is incorrect. ANY must be used with a comparison operator, such as <, = an do on. See 4.6.14 of the JPA Specification and the BNF for comparison_expression in section 4.14 of the JPA Specification. Option D is incorrect. SOME must be used with a predict, such as <, = and so on. (See 4.6.14 of the JPA Specification.) Location: > Section 8: Java Persistence Query Language > Objective 8.4 > Question 45

A Leopard entity is in a one-to-many bidirectional relationship with a Spot entity. Given an excerpt from the Leopard entity denoting this: 10. @OneToMany(mappedBy="spoton", fetch=FetchType.LAZY) 11. Collection<Spot> spots; The following code is found in a stateful session bean, intended to delete those leopards who do not have spots: 18. @TransactionAttribute(TransactionAttributeType.REQUIRED) 19. public void removeSpotlessLeopards() { 20.

em.persist(new Leopard("meow"));

21.

em.createQuery("DELETE FROM Leopard l " +

22. 23.

"WHERE l.spots IS EMPTY ").executeUpdate(); em.createQuery("SELECT l FROM Leopard l ").getResultList();

24. } Which statement is correct? A It is NOT necessary to execute this code within a transaction. B The syntax of the DELETE FROM JPQL statement is invalid. C The query on line 23 is guaranteed to return an empty list. D This type of code is recommended against in the JPA Specification. Reference Option D is the correct answer. (See 4.10 of the JPA Specification and in particular, see the caution.) Option A is incorrect. The JPA Specification demands that this be executed in a transaction, or else a TransactionRequiredException is thrown. (See 3.6.1 of the JPA Specification.) Option B is incorrect. The syntax is correct. (See 4.10 of the JPA Specification.) Option C is incorrect. There is no guarantee. Line 22 executes against the database, bypassing the persistence context. As a result, the developer might find the instance in line 20 still available in line 23. Location: > Section 8: Java Persistence Query Language > Objective 8.5 > Question 46

An Order entity (in the package foo) has an id and name field. Given an entity manager em, which statement can successfully create a Query object? A em.createSQLQuery("SELECT id, name FROM Order", Object) B em.createQuery("SELECT o FROM Order o") C em.createNamedQuery("SELECT o FROM Order o") D em.createQuery("SELECT o FROM Order o", foo.Order.class) Reference See section 3.1.1 of the JPA specification. Option A is incorrect because native queries are created with createNativeQuery Option B is correct. Option C is incorrect because the developer should supply the name of the query, NOT a query itself. Option D is incorrect because it is mixing the syntax for creating native queries (adding a class as second parameter erroneously) and dynamic queries (the syntax of the first parameter is valid Java Persistence API query language).

Location: > Section 8: Java Persistence Query Language > Objective 8.6 > Question 47

Given an excerpt from a Book entity: 10. @Entity 11. public class Book { 12. @Id private Integer id; 13. public String bookName; 14. @Enumerated( EnumType.ORDINAL ) 15. public Status status; 16. @Temporal(TemporalType.TIMESTAMP) 17. public java.util.Date loanDate; 18. public enum Status {IN, OUT}; 19. /* ... */ 20. } A developer constructs the following Query instance: 40. Query q = em.createQuery("select b from Book b where " + 41. "b.bookName=:n and b.loanDate=:d and b.status=:s"). 42. setParameter("d",new Java.util.Date()). 43. setMaxResults(2). 44. setParameter("n", "A"). 45. setParameter("s", 0). 46. setFirstResult(0); Which line causes a runtime exception to be generated? A Line 41 B Line 42 C Line 43 D Line 44 E Line 45 F Line 17

Reference Option E is correct. The status field of Book is an enum. Even though the annotation on line 15 maps it to an ordinal in the database, its type is still an enum in the query. So passing 0 instead of Status.IN for example, is a type error and results in an exception. Options A, B, C, and D are incorrect because the rest of the calls on the Query API are correct. (See 3.6 of the JPA Specification.) Option F is incorrect because there is nothing wrong with using java.util.Date as long as the developer uses the @Temporal annotation. (See 9.1.20 of the JPA Specification.) Location: > Section 9: Transactions > Objective 9.1 > Question 48

Which statement about transaction demarcation is correct? A A session bean can be designed with bean-managed and container-managed transaction demarcation, at the same time. B A message-driven bean can be designed with bean-managed and container-managed transaction demarcation, at the same time. C Entities can be designed with bean-managed or container-managed transaction demarcation, but not with both at the same time. D Both stateless and stateful session beans can designed with bean-managed transactions. . E Only stateless session beans can be designed with bean-managed transactions. References Option D is correct. (See 13.3.1 of the Core Specification.) Options A and B are incorrect because the developer cannot use both bean-managed and containermanaged transaction demarcation at the same time. Option C is incorrect because Option D is correct - The developer cannot specify the management type. Option E is incorrect. The developer can have bean-managed transactions with stateful beans. (See 13.3.1 of the Core Specification.) Location: > Section 9: Transactions > Objective 9.2 > Question 49

A client makes a request to the yummy method of a stateless session bean, shown below: 10. @Stateless 11. @TransactionManagement(javax.ejb.TransactionManagementType.BEAN) 12. public class SoupBean implements Soup { 13. @Resource javax.transaction.UserTransaction ut; 14. @EJB Carrot carrot; 15. public void yummy() {

16. ut.begin(); 17. carrot.peel(); 18. ut.commit(); 19. } 20. } The Carrot bean is a stateless session bean using container-managed transactions. It has the following definition for the peel business method: 30. @TransactionAttribute(REQUIRED) 31. public void peel() { 32. } No descriptor files are used. Which statement about the transaction behavior is correct? A If the client is associated with a transaction, the server throws an exception on line 16. B If the client is associated with a transaction, it is suspended before the yummy method is invoked. An exception is thrown when this method invokes the peel business method. C If the client is associated with a transaction, it is suspended before the yummy method is invoked. The yummy method starts a new transaction, which is suspended before the peel method is invoked, and resumed after the peel method exits. After the yummy method exits, the client's transaction is resumed. D If the client is associated with a transaction, it is suspended before the yummy method is invoked. The method call to peel does not suspend or resume transactions. After the yummy method exits, the client's transaction is resumed. Reference Option D is correct. If a client in a transaction makes a call to a method in a bean-managed transaction instance, the client's transaction is suspended until that call exits. See Table 12 and the explanations in section 13.6.1 of the Core Specification. At line 17, a transactional context has been created, so no new context must be created to invoke peel. Options A, B, and C are incorrect because they do not follow these rules. For example, no exceptions are thrown because it is quite legitimate to call a bean-managed bean from a client in a transactional context (see 13.6.1 of the Core Specification), so Options A and B are incorrect.

Location: > Section 9: Transactions > Objective 9.3 > Question 50

Given a code excerpt from a session bean: 10. @Stateful 11. @TransactionManagement(BEAN) 12. public class LookingForTroubleBean implements LookingForTrouble { 13. @Resource javax.Transaction.UserTransaction ut; 14. @Resource DataSource ds1; 15. @Resource DataSource ds2; 16. Connection con; 17. 18. public void zubb() { 19.

Statement stmt;

20.

ut.begin();

21.

con = ds1.getConnection();

22.

stmt = con1.createStatement();

23.

stmt.executeUpdate("INSERT INTO CULPRITS VALUES (1)");

24.

con.close();

25. } 26. @Remove 27. public void buzz() { 28. Statement stmt; 29. con = ds2.getConnection(); 30. stmt = con2.createStatement(); 31. stmt.executeUpdate("INSERT INTO CULPRITS VALUES (2)"); 32. con.close(); 33. ut.commit(); 34. } 35.}

Assume that the tables and JTA datasources are setup correctly, and that the update statements are valid and do NOT cause an exception. A remote client, which is NOT executing in a transactional context, locates an instance of this session bean and calls method zubb, and then the method buzz. Which statement is correct? A An exception is thrown when the method zubb ends. B An exception is thrown when the method buzz ends. C No exceptions are thrown. This is valid code. D An exception is thrown on line 29. E An exception is thrown on line 33. Reference Option C is correct. A stateful session bean can retain a transaction across client calls. (See 13.3.3 of the Core Specification.) Options A, B, and D are incorrect because the code is correct. No exceptions occur because of the transactional setup. See Option C. Location: > Section 9: Transactions > Objective 9.4 > Question 51

Given two excerpts from the implementation of a session bean MySessionBean: 10. @TransactionAttribute(REQUIRES_NEW) 11. public class MySuper { 12. public void foo() {} 13. public void bar() {} 14. } 30. @Stateless 31. @TransactionAttribute(NOT_SUPPORTED) 32. public class MyBean extends MySuper implements MyI { 33. public void foo() {} 34. @TransactionAttribute(SUPPORTS) 35. public void bar() {} 36. }

A deployment descriptor contains the following information pertaining to the transaction settings:

10. 11. <method> 12. <ejb-name>MySessionBean 13. <method-name>foo 14. 15. Mandatory 16. foo and bar are business methods defined in interface MyI. Which statement correctly defines the transaction attributes assigned to the methods foo and bar respectively? A REQUIRES_NEW, SUPPORTS B REQUIRES_NEW, REQUIRES_NEW C MANDATORY, REQUIRES_NEW D MANDATORY, SUPPORTS E NOT_SUPPORTED, SUPPORTS F NOT_SUPPORTED, REQUIRES_NEW Reference Option D is correct. foo is set to REQUIRES_NEW in the superclass. It is overridden to NOT_SUPPORTED in the session bean, and later overridden again to MANDATORY when the descriptor bar's transaction attribute is set to SUPPORTS in the session bean. Options A, B, E, F, and C are incorrect because the correct order is described in Option D.

Location: > Section 9: Transactions > Objective 9.5 > Question 52

Given an excerpt from a stateful session bean: 10. @Stateful 11. public class MyStatefulBean implements MyStateful, SessionSynchronization { 12. @Resource SessionContext ctx; 13. public void afterCompletion(boolean f) {} 14. public void beforeCompletion() { ctx.setRollbackOnly(); } 15. public void afterBegin() {} 16. public void inc() {} 17. } The MyStateful interface is a local business interface that declares inc to be a business method. No deployment descriptor is used. A stateless session bean using container-managed transactions has a business method that acts as a client: 20. @TransactionAttribute(TransactionAttributeType.REQUIRED) 21. public String doIt() { 22. ms.inc(); 23. } The method doIt is called without a transactional context. Which statement properly reflects the order of method invocation? A doIt, beforeCompletion, afterBegin, inc, afterCompletion B doIt, inc, beforeCompletion, afterBegin, afterCompletion C doIt, inc, afterBegin, beforeCompletion, afterCompletion D doIt, afterBegin, inc, beforeCompletion, afterCompletion E doIt, inc, afterBegin, beforeCompletion Reference Option D is correct. doIt is called first, as indicated in the question. Because you are now in a transactional context, the container then invokes afterBegin before it invokes the business method. (See 13.6.2.11 of the Core Specification). After, the business methods, beforeCompletion and afterCompletion are called. (See 4.3.7 of the Core Specification). The code in beforeCompletion causes an exception to eventually be generated, but afterCompletion is still called (with false). Options A, B, C, and E do not agree with this order and so are incorrect.

Location: > Section 10: Exceptions > Objective 10.1 > Question 53

Which statement is true about session beans and exceptions? A The methods of the business interface can declare any application exceptions. B Business methods can throw any type of exception. C Business method interceptors cannot throw exceptions. D All exceptions that can be thrown in a business method must be caught and wrapped in an EJBException. Reference Option A is correct. (See 3.3 of the Simplified Specification.) Option B is incorrect. It cannot throw java.rmi.RemoteException. See 3.3 of the Simplified Specification.) This does not contradict Option A. Option C is incorrect. They can. (See 3.4 of the Simplified Specification.) Option D is incorrect. There is no requirement for this in the specification. Location: > Section 10: Exceptions > Objective 10.2 > Question 54

Given the complete code defining an exception that is declared and thrown within the business method of a stateful session bean: 10. public class OhException extends RuntimeException { 11. } The business method runs in a transactional context. Which statement about the exception behavior is correct? A The business method cannot throw instances of OhException. B This exception is an application exception. C This exception rolls back the transaction. D This exception must be declared in the throws clause of the method. Reference Option A is incorrect. There is no restriction on this kind of exception. Just RemoteException. (See 3.3 of the Simplified Specification.) Option B is incorrect. It has NOT got an ApplicationException annotation. (See 14.2.1 of the Core Specification.) Option C is correct. It is a system exception. (See 14.2.2 of the Core Specification.) Option D is incorrect, it need NOT. It is a runtime exception.

Location: > Section 10: Exceptions > Objective 10.3 > Question 55

Which EJB role is responsible for taking actions to correct problems that cause non-application exceptions? A Enterprise Bean Provider B System Administrator C EJB Container Provider D EJB Server Provider Reference See 14.5 of the Core Specification. Option B is correct because this is the role of the system administrator. Options A, C, and D are incorrect because A is correct.

Location: > Section 10: Exceptions > Objective 10.4 > Question 56

A stateless session bean contains the following business method: @TransactionAttribute(TransactionAttributeType.REQUIRED) public String getVal() throws EJBException, Exception { throw new java.lang.Exception("Surprise!"); } What is the result if a client calls this bean? A It receives a null value. No exception is received by the client. B The client receives an exception that is an instance of java.lang.Exception (NOT a subclass of this type). C The client receives an exception that is an instance of javax.ejb.EJBException (NOT a subclass of this type). D The client receives an exception that is an instance of java.rmi.RemoteException (NOT a subclass of this type). Reference Option B is correct because this is an application exception and these passed "precisely" to the client so it gets the same exception. (See 14.1.2 of the Core Specification.) Options A, C, and D are all incorrect because B is the correct answer. All the others are not instances of java.lang.Exception but instead are subclasses.

Location: > Section 10: Exceptions > Objective 10.5 > Question 57

A business method in a stateful session bean accesses the EJBContext.getRollbackOnly method. When will a call to the getRollbackOnly method throw an exception? A If the business method executes with a REQUIRED transaction attribute. B If the business method executes with a REQUIRES_NEW transaction attribute. C If the business method executes with a SUPPORTS transaction attribute. D If the business method executes with a MANDATORY transaction attribute. Reference Option C is correct. (See 13.6.2.9 of the Core Specification.) It is handled for the other three transaction attributes in Options A, B, and D and so it does NOT throw an exception for these attributes. Location: > Section 11: Security Management > Objective 11.1 > Question 58

Given an excerpt from a stateless session bean: 10. @Stateless 11. @RolesAllowed("BOND") 12. public class YourBean implements MyI { 13. /* ... */ 14. } The bean also has a deployment descriptor, and given an excerpt: 20. 21. <security-role> 22.

JAMES

23. 24. Which roles must be mapped to security principals and groups to secure this session bean? A BOND B JAMES C JAMES and BOND D No roles

Reference Option C is correct because RolesAllowed and the role-name declare roles that should be mapped. See 17.3.1 of the Core Specification where it mentions that the security-role augments the aggregation of other roles defined in the descriptors. Options A, B, and D are incorrect because C is correct. Both roles must be mapped. Location: > Section 11: Security Management > Objective 11.2 > Question 59

Given a snippet from a stateful session bean: 10. @Resource DataSource myDS; 11. 12. public void doSomeWork() { 13. Connection con = myDS.getConnection(); 14. } Assume that this bean must be deployed into an established application server that has security principals already configured. Which EJB role is responsible for making sure that if this code is left unchanged, the call on line 13 does NOT fail with a security exception? A Bean Provider B Application Assembler C Deployer D System Administrator Reference Option C is correct. Because this code does NOT perform manual authentication from the resource manager when it retrieves the connection, it is up to the Deployer to configure this correctly. (See 16.7.2 and 16.7.1.2 of the Core Specification for an example.) Option A is incorrect. In this case you have asked that the code be left unchanged. When deployed, it is the Deployer who is responsible for the security role assignment, not the Bean Provider. Bean Providers and Application Assemblers can supply security roles, but even these are not sufficient. The Deployer must tie these roles with real security information. (See 17.1 of the Core Specification.) Option B is incorrect for the same reason as A is incorrect. Option D is incorrect because it is NOT the role of a system administrator to ensure that code has its security profile properly configured. The question states explicitly that the security principals have been configured, so it is a matter of mapping the roles to these principals, and that is the role of the Deployer.

Location: > Section 11: Security Management > Objective 11.3 > Question 60

Given an excerpt from a stateless session bean that has a business method barbar: 9. // ... 10. @Stateless public class FooBean implements IFace { 11. @Resource SessionContext ctx; 12. // .. 13. public void barbar() { 14. // ... 15. String name = ctx.getCallerPrincipal().getName(); 16. // ... 17. } 18. } 19. } There is no associated deployment descriptor. Which statement is correct about this code? A A @RolesAllowed or @DeclareRoles annotation is needed at line 9 to make this execute without runtime exception. B Line 15 can sometimes throw a null pointer exception. C This code execute without a problem. D No matter what annotations are added, this code raises a java.lang.IllegalState exception. Reference Option A is incorrect. This has nothing to do with getCallerPrincipal operation. (See 17.2.5.1 of the Core Specification.) Option B is incorrect. The only way for that to happen would be if the context were null (but it is injected so it will NOT be) or if the getCallerPrincipal returned null, which it is NOT allowed to do. (See 17.6.5 of the Core Specification.) Option C is correct. This is legitimate code. (See 17.2.5.1 of the Core Specification.) Option D is incorrect. It is legal to make a call to getCallerPrincipal in a business method of a stateless bean. (See 4.5.2 of the Core Specification.)

Location: > Section 11: Security Management > Objective 11.4 > Question 61

Given a snippet from a descriptor defining some security properties in two session beans: 10. <session> 11. <ejb-name>BeanB 12. ... 13. <security-identity> 14. 15. hyde 16. 17. 18. ... 19. 20. ... 21. <session> 22. <ejb-name>BeanC 23. ... 24. <security-identity> 25. 26. jekyl 27. 28. 29. ... 30. A business method in BeanA (not shown here) makes a call to a business method in BeanB, which in turn makes a call to a business method in BeanC. No other method or class security annotations or metadata is used. Furthermore, the call into BeanA is made by an authenticated user in the security role hyde. Which statement is correct? AThe beans do NOT deploy unless a security identity is specified for Bean A as well. B The call from BeanA to BeanB fails with a security exception. C The call from BeanB to BeanC fails with a security exception. D The business methods in BeanC runs under the security role hyde.

Reference Option A is incorrect. The developer does NOT need to specify one, it defaults to caller identity. See 17.3.4 of the Core Specification.) Options B and C are incorrect. There is nothing to indicate an exception is raised. Option D is correct. It does this by hyde not jekyl. (See 17.3.4.1 of the Core Specification.)