Ralph Jaus

Why we need serilizable Interface in Employee class??

The underlying rmi protocoll requires that all objects that are invoked remotely have to be serializable.

What happens if the Employee class implements the Serializable interface ?

What makes me wonder, too, is the error message part "box.Employeer ": Nowhere in your code the word "Employeer" occurs!

Hi Christian,

saving messages in a database has of many advantages with regard to safety, archiving, making statistics, etc. In a project I was working on, all incoming and outgoing messages were saved in a db and finally that db was the main tool for testing and for maintenance in production. For instance, when a customer complained about something we where able to look at the db and to prove that he had sent the wrong data. So I can highly recommend the db-solution.

Nevertheless let me describe a solution that solely uses the queue: Instead of using a MDB that reads the queue you can use a SLSB that's accessed by the users who want to read the messages. The invoked business method reads the message from the queue and returns the content to the user. Since the messages are read first-in-first-out from the queue (if configured accordingly) you get the behavoir you want. You could even replace the SLSB by a singleton bean in order to be completely sure about serialization.

That's a reasonable decision. From "Pro EJB 3" I read the chapters

1-8: completely
9 : all but "Schema Generation"; moreover I think native queries and SQLResultSetMapping aren't that important (no corresponding questions in my exam)
10 : Just read it to get a feeling (no memorizing)
11 : all but "Outside the server"

There are some more subsections that aren't necessary with respect to the exam - but that will become clear from context.

If you're preparing for SCBCD 5, I hardly doubt if reading the JPA2 version of Mike's book makes sense. For, SCBCD 5 concerns only JPA 1 and

- there are many extensions in JPA 2 against JPA 1 that you don't need to know for SCBCD 5
- some restrictions in JPA 1 doesn't exist in JPA 2 any longer; this may effect exam questions. For example: The answer of "Can embeddable classes be nested ?" is "no" in JPA 1 and "yes" in JPA 2. There are many examples of this kind.

Better use the JPA1 version of Mike's book (Pro EJB 3) for SCBCD 5.

Siva Masilamani wrote:In the above code what the ejb annotation says?

From JEE-API: The name element from javax.ejb.EJB defines "The logical name of the ejb reference within the declaring component's (e.g., java:comp/env) environment."

Thus, in your example, the app client deploy tool creates an entry in the app client's ENC with name "java:comp/env/TestSLAnnotationBean". During runtime the app client container performs dependency injection before it calls the app client's main method (see, for instance, JEE 6 spec, section EE.10.4).

I agree. But don't worry, it's unlikely that such mistakes occur in the exam (unless the oracle guys turn it upside down ).

umakanth godavarthy wrote:This is bit contradicting to the previous statement as, if env entries are not specified in DD it is not accessible though context lookups.

Yes, I agree. But environment entries are the only exception from this rule. An explanation might be:

Entries in the ENC (the ejb's jndi subdirectory) are created during deployment. When a bean instance is created the
container performs a JNDI lookup on the ENC and assigns the retrieved object to the injection target (e.g. the annotated
instance variable).

Now assume there is no entry in the ENC. What should the container do ?

The simplest solution would be to allow default values. That works pretty fine with types that are independent of the
container's environment, such as environment entry types (String, Integer, etc). But what should be the default value of

@PersistenceContext EntityManager em; ?

It had to be something like

@PersistenceContext EntityManager em = new HibernateEntityManagerImpl();

But then the bean code depends on the container's environment, breaking EJB's philosophy of platform-independence.
Therefore default values are no option for such types. So for these types we need entries in ENC (in contrast to
environment entry types).

On the other hand, if we have

@Resource int = 3;

(and no DD entry) it would surely be possible for the container (in principal) to generate a corresponding entry in ENC like
it must be done for the other types. But what would be the usage of it ?

To my knowledge

@Resource int envEntry=99;

works as follows: If there is a corresponding entry in DD then the value is taken from DD, otherwise the default is taken. But in contrast to other resources no entry in the beans ENC is created. Therefore the lookup fails. If you inject for example

@PersistenceContext private EntityManager em;

the following returns an entity manager object:

ic.lookup("java:comp/env/com.scbcd.ejbs.StatefulBeanExample/em");

Ismael Upright wrote:After that I expect to have a bookShop in database as well as books: "Planets" and "Galaxies", and book "Stars" to be deleted.

It's not possible with JPA (at least JPA 1) to delete entities in a one-to-many relationship from db through changing the list of related entities and merging. Deletion from db always requires some remove or delete command.

Ismael Upright wrote:book1 = new Book();
book1.name = "Galaxies";
book1.shop = bookShop;
dao.update(shop);

I actually wonder somewhat that this led to an insertion of a book. For, the entity shop is updated but the new entity that is referenced by book1 has never been added to shop's list of books.

Appropriate data access layer design depends on characteristics of the application like data volume, performance requirements (do you need fast inserts, selects, both ?), average number of concurrent requests, etc. Therefore, based on your information, it will be difficult to give proper suggestions.

However, the following came into my mind:
1. insert the item record
2. commit the transaction
3. count the number of records having the same name like the record that has just been inserted
4 if the number is greater than one, remove the record again

Remarks:
- It's possible that both records of two concurrent requests will be refused.
- Concerning uniquness of names, the database may be in inconsistent state during steps 3 and 4. However, if a timestamp is available and there is a request, that selects a record for the name in question, you know by timestamp that the older record is the correct one and the other only exists temporarily.
- If data volume is large it surely needs an index or some other database facility to make the select count work with good performance.

Anyway, it's an interesting problem. Please, let us know about your solution.

If there are only reading operations from a database and no other resources hava to be synchronized then it's better not to use transactions in the concerning ejb method. It's not only JTA overhead but also overhead for maintaining the persistence context (if you're using JPA).

Transaction attributes that prevent using transactions are NEVER and NOT_SUPPORTED. But in general it's safer to use NOT_SUPPORTED.

Siva Masilamani wrote:what files need to be given to the client?

If the app client container is installed on the client machine the app-client-jar is sufficient.But according to your questions it seems you have to distribute your application to a couple of clients. In this situation each vendor has its own strategies. Glassfish, for example, offers

- Java Web Start to download the client application from the app server to the client
- bundling the app client container and the client application into a jar that then has to be distributed to the clients.

I don't know about websphere, but I've come across the following webpage. If it's reliable then websphere seems to offer similar approaches ...

All in all, not much is standardized about application clients in the JEE spec.

Siva Masilamani wrote: How it would be different to access the EJB components from stand alone client to the client runnng under the Application client container?

The main difference I see is that you can use some container services in your client if it's running in the Application client container. For example: With an Application client container you can use dependency injection to access an ejb while a standalone client has to do a JNDI lookup.

Siva Masilamani wrote:Lets say i have Swing application which needs to access EJB deployed in a remote server, so i will make this swing application as Application client(under the container) with DD and deploy it in the server where my ejb is deployed and generate the client jar file and distribute it to the client and make the client to invoke this client jar file using the tool provided by my container?

All you need is the client jar (irrespective it's packaged with an app server IDE or, say, "by hand"). Then you can run the client with the Application client container.

Hi Anish,

an example for using MesageConsumer.receive() is provided by the following code excerpt: Context ctx = new InitialContext(); ConnectionFactory connectionFactory = (ConnectionFactory) ctx.lookup("jms/ConnectionFactory"); Queue destination = (Queue) ctx.lookup("jms/Queue"); Connection connection = connectionFactory.createConnection(); Session session = connection.createSession(false,Session.AUTO_ACKNOWLEDGE); MessageConsumer messageConsumer = session.createConsumer(destination); connection.start(); Message message = messageConsumer.receive(); if (message instanceof TextMessage) System.out.println( ((TextMessage)message).getText() ); else System.out.println("unknown message type"); Hope this helps.