Nicolas Stern

Ranch Hand
+ Follow
since Apr 26, 2002
Merit badge: grant badges
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Nicolas Stern

Hi everyone...

Apologies if the problem has already been discussed.

I'm refering to this thread:

We are using Spring Framework 2.5 and Hibernate 3.3.1, using hibernateTemplate.

We are wondering if we use the appropriate way to clear the session cache when executing a query in a loop, so thanks for any suggestion.

The problem is the following: the details records are configured to be eagerly fetched. But when querying the master records in a loop, the details are cached - which is undesirable.

Clearing the session at the end of the query (session.clear()) solves this caching problem ... but is there a better way ?

Thanks for any input

Cheers - Nicolas Stern
Nested transaction :

Your assumption is wrong. See core specs paragraph 13.1.2 Transaction Model:

The Enterprise JavaBeans architecture supports flat transactions. A flat transaction cannot have any child (nested) transactions

Regarding the attributes REQUIRED and REQUIRES_NEW, see the paragraph and


If a client invokes the enterprise bean�s method while the client is associated with a transaction context, the container invokes the enterprise bean�s method in the client�s transaction context.


If the client invokes the enterprise bean�s method while the client is not associated with a transaction context, the container automatically starts a new transaction before delegating a method call to the enterprise bean business method.
If a client calls with a transaction context, the container suspends the association of the transaction context
with the current thread before starting the new transaction and invoking the business method.

... and perhaps you should read the Persistence chapters of EJB in Action. These issues are well described - well enough to pass the exam.

Cheers - Nicolas
Hi everybody,

...perhaps my thinking's getting fuzzy...thanks for helping me putting the pieces of the puzzle together.

According to the core specs. par. 4.4.1 "Operations Allowed in the Methods of a Stateful Session Bean Class", a business method of a SFSB can have access to timer methods.

According par. 18.2, only SLSB and MDB and 2.1 Entity beans can be registered to the timer service. Timers cannot be created for SFSB or entities.

What am I missing ? Why should a SFSB access timer methods for ?

Thanks in advance - Cheers - Nicolas
You are mixing the concepts of Transaction Boundaries (Container-managed or application-managed) and persistence context(which can be also container or application-managed).

UserTransaction.begin() and UserTransaction.commit() relates to Application-managed transaction boundaries.

EntityManager.joinTransaction() can be called when the entity manager instance has been created outside of an active transaction.

Have a look at the example of the Persistence Specifications - it demonstrates exactly this situation.

HTH - Cheers
Regarding your 2. question: look at the specs paragraph - Injection of EJB References:

The following example illustrates how an enterprise bean uses the EJB annotation to reference another enterprise bean. The enterprise bean reference will have the name java:comp/env/com.acme.example.ExampleBean/myCart in the referencing bean�s
naming context, where ExampleBean is the name of the class of the referencing bean and
com.acme.example its package. The target of the reference must be resolved by the Deployer.
package com.acme.example;
@Stateless public class ExampleBean implements Example {
@EJB private ShoppingCart myCart;

Hth - cheers - Nic
Hi Anu,

Regarding your point, I agree with you - I had the same doubt when I found this question in the Enthuware TestSimulator. The answer provided is wrong - or there is a typo in the question. The specs are clear (Cf. Core Specs, par. 21.1.1 APIs Provided by Container :

The Java EE platform also requires a number of optional packages. The following optional packages are
required to be provided in EJB containers:
� EJB 3.0, including the Java Persistence API
� JTA 1.1
� JMS 1.1
� JavaMail 1.4 (for sending mail only)
� JAF 1.1[99]
� JAXR 1.0

hth - cheers - Nic

I have a doubt about a mock exam question.

According to the core specs (4.6.5) : the business method must be public.

Now the mock exam question:
Given the following interface:

Which method of the following bean are exposed to local clients ?:
public class MyBean implements MyI {
public int m1() { return 1; }
public int m2() { return 2; }

The answer provided says that both methods m1() and m2() are exposed to local client.

I had thought that since client acces bean via their interface, only m1() is exposed to local clients.

I assume the answer provided with the mock exam must be correct, but I have a doubt, because the spec is clear on this point.

Thanks for any input

Hi Johan

there is a faq mentionned here

I used it to prepare for the exam, and that was enough.

HTH - Cheers - Nicolas
Hi archana,

No, I didn't get a confirmation email.

Once you've uploaded the assignement, you can register for the exam. AFAIK your assignment will be reviewed only after you've completed the exam.

Cheers - Nicolas

the line

references the member variable s2 of your instance ref1. Expected is a valid expression or a statement (e.g. an assignment, a method invokation)


hth - cheers
15 years ago
Hi - I just started preparing the SCBCD (I already have SCWCD), but I was considering re-certifying on Java 5 with the upgrade exam, since my programmer exam is now quite old (1.2) ...

Cheers - Nic
Hi pablo,

I think adding methods to the interface is penalized by automatic failure.

My assignment states :

Your data access class must be called "", must be in a package called "suncertify.db", and must implement the following interface:

Which does not mean you can't add methods to your Data class. But I think the interface DBMain must be used as is.

HTH - Cheers - Nicolas
[ January 07, 2008: Message edited by: Nicolas Stern ]
... Finally...

It took me a loooooong time to complete the whole thing - the better the feeling when it's finally completed.

I guess the effective time working on the assignement must have been 200 hours, but I spent a lot of time besides in readings, tutorials and prototypes. Professionnally, I'm not writing a lot of Java (I'm mostly in the databases fields) and I had a pretty steep learning curve.

Score in details:

General Considerations (maximum = 100): 100
Documentation (maximum = 70): 70
O-O Design (maximum = 30): 30
GUI (maximum = 40): 31
Locking (maximum = 80): 80 Data store (maximum = 40): 40
Network server (maximum = 40): 30

Javaranch threads helped me a lot. And, of course, Andrew Monkhouse and Terry Camerlengo's SCJD Exam with J2SE 5.

I ended up with 41 classes and about 4300 lines of code (incl. comments and javadoc comments, which I made pretty extensively).

Main patterns used: factory (whenever needed), adapter (to bridge the client/server to the RMI server), and singleton (for the class accessing the database file and the one keeping track of the locked records). All of this has already been pretty much discussed in this forum, and I did not bring any revolution, so I won't go into the details. Read Andrew Monhouse's book !

I was glad about the good scores in the doc, because I invested pretty much in explaining my choices and assumptions, and also in my userdoc. Both results in 22kb text files each. I also tryied to make the Javadoc as complete as possible.

I don't know where I lost points in the GUI and in the network server, but this could be that I was penalized for not implementing all the methods in the interface provided - there is a pretty long discussion on this forum about this aspect of the assignment on this thread:

I think the most useful thing was using JUnit - it was always a good feeling to see the green bar after having left the assignment for a while...

He are a few posts that I found contained some useful information at some points during my development:

design (ken krebs):

design (passed - thread with score 100%)

Design :

Locking, synchronization :

Delete flag:

Use of singleton:

Use of a shutdown hook:

Exception handling:

Find method

Should lock methods be callable by the client:

Cheers - Nicolas
Problem solved.

I did not realize that the pdf generation process explicitely encrypted the file. All we had to do was to proceed to encryption later in the process.

Cheers - Nic
15 years ago

I have the follwing problem using iText.

I�m getting a byte array that is generated using a pdf generator library.

When I try to instanciate a PdfReader from this byte array, � Encrypted files are not supported � is thrown

When the same byte[] is viewed in Adobe Acrobat Reader (after having been sent to the browser with the according MIME type) and then saved physically, the file can be opened as argument to instanciate the pdfReader.

Looks like my byte array is recognized as an encrypted pdf.

The byte array is generated from a separate library from HTML.

What I don't get is why iText can open the file that has been created from the Byte array, but not the byte array itself.

Any hint ?

Thanks in advance
15 years ago