Serkan Yazici

All,

Got my score sheet for the beta exam today If anyone is wondering, the passing score is 59% out of 72 questions. I got 65 correct out of 72 questions that were scored for me.

I was half-expecting to see the correct/incorrect/updated/dropped break- down of all 166 questions. I assume they have scaled the correct/incorrect answers from the questions weren't dropped from the beta (At least I hope they didn't just randomly select any 72 out of 166) I probably didn't do as well with the last 60 questions in the beta. After 3.5 hours answering the first 106 questions, I was hungry, tired, and dying for a smoke So I spend another 30 minutes to quickly scan the last 60 questions and select the first reasonable answer I spotted. I feel I could do much better with the standard exam by double checking my answers, etc. But I certainly enjoyed the beta experience It was a test of endurance as well as Java.

Good luck to everybody else waiting for their results.

-- Serkan

Originally posted by Mark Spritzler:


Actually, what this says, to me, is that it will not be extended again, and that Everyone who pays and takes the Beta will receive the voucher, even if you are over the first 500.

Mark

So, does this mean we can take the beta a second time for a second voucher?

... Anyways ....

I think this version of the certification exam is much better than the previous one. I found it quite enjoyable and I think it measures the level of actual programming skill better than its predecessor. On the beta, there was only a single question that I've found utterly pointless, and I believe there were less than 10 minor errors (that I could spot). My only problem was the sheer amount of questions, and time it took to go through them.

Man... that was a test of endurance! and I'm glad that Sun decided to offer this voucher (so we can go through another 2 hours of intensive brain gymnastics)

I think allowing static local variables in methods would have been a good idea. When you need the methods to remember their instance-independent state between calls.

I know, I know... you can still maintain this state information with static class variables but the idea is to have maximum encapsulation possible (if a member variable is only used to keep the state information about a single method, why expose it to the rest of the class).

I'm not too bothered about not having them though.

Originally posted by Mark Spritzler:
Feb 5th.

Mark

Ah... the same day as me. Good luck

I've just finished skimming through the developer notebook today, and realised I've got to read something with greater detail. Hopefully, I'll also do some coding practices over the next two weeks (work permitting).

I'm taking it on 5th of February. Although we are not using Java 5 at work yet (may be towards the end of the year, when we plan major upgrades), 26 quid for the Beta exam was just irresistable Hopefully, next 3 weeks will be enough to do enough reading and practice, kinda busy nowadays.

Although I use Java 1.4 night and day; I never had a chance to look at new Java features before (apart from reading a couple of high-level tech articles). Man, do I like what I see I kind of wish they also incorporated method-templates and default arguments as well.

I've never taken a beta exam before, so I assume we will not get a pass/fail report at the end, and probably no correct/incorrect answers break down. Any insiders around to confirm it?

How about when the beta results/certification kit will be available?

By the way, good luck everyone, and try to do extremely well to keep the passing score high

Thanks a lot everybody!

I forgot to mention the JavaRanch forum is also a great help and fun during my studying as well. Especially so for the developer certification. Thanks a bunch.

Wow, a comment from Bert Bates himself Thanks for a great book. I almost wish I hadn't done the web component cert so I could read the new HF Servlets book. Maybe if I find the time, I'll do the 1.4 upgrade next year using the new book. I sure could use a laugh

Happy new year!

Hi all,

Passed SCBCD with 97% today. I've been revising for about 3 months on and off (mostly reading on the tube with about 5-6 hours studying per week.

I can recommend the HF EJB book (excellent book), sun's ejb specs (definitely skim through if you are studying for SCBCD as well), Mikalai's study notes (thanks ), and EJBCertificate.com tests. I didn't feel the need to use any other commercial mock exam simulator.

Merry X-mas everyone and good luck to anyone still studying for the exam.

Originally posted by Mark Lybarger:
i'm on board with jyothi on this one. seems like 1 is correct to me.

if a bean throws an application exception the transaction _may_ be doomed, but the client can't tell. the client can either contine processing (even retry the same operation ).

If a transaction started by the client, client can check if the transaction was marked for rollback or not the same way as BMT beans (using the UserTransaction.getStatus method). So if safely phrase means knowing that the transaction can definetely be committed, then option (2) would be more correct.

However, IMO this is a very ambigiously worded question and I wouldn't lose too much sleep over it

Originally posted by nachagoni rishi:

4. A local client cannot continue a transaction if javax.transaction.TransactionRolledbackLocalException is received.

why is option 4 wrong.

Because the correct name of this exception is javax.ejb.TransactionRolledbackLocalException
[ November 19, 2004: Message edited by: Serkan Yazici ]

Hi Nitin,

I had the same problem (not the CORBA BAD_OPERATION but NO_PERMISSION exception). I did a search here and found the following suggestion:

Originally posted by Dan Young:
Just a small addendum:

Tried all KS's suggested remedy steps. Got the following:

java.rmi.AccessException: CORBA NO_PERMISSION

Poked around on Google and found this:

With 1.3.1 final release, the J2EE SDK became strict about checking adherence to the security policies of J2EE components.

Fix:

Under the Security screen of the EJB wizard or the Security tab of the EJB inspector in deploytool, click "Deployment Settings..". Under the box "Client Authentication", make sure "Support Client Choice" is checked instead of "Certificate" or "Password".

2. Using Deploytool click "Update & Redeploytool"

3. Run you standalone client again

Cheers,
DY

I'm using J2EE 1.3.1 and it solved my problem. Hope it helps.

Hi Along,

I think what the instructions want to make clear is don't worry about the endian format for the numbers (In other words, readShort/readInt/writeShort/etc specified in DataOutput and DataInput interfaces and implemented in DataInputStream and DataOutputStream classes will work fine).

Since RandomAccessFile implements both interfaces as well, using RandomAccessFile is fine too. In fact, if Java supported multiple implementation inheritance; RandomAccessFile would probably directly extend DataInputStream and DataOutputStream classes and leave read/write methods intact

Hi Marcus and all,

If you have noticed I didn't post the whole locking code in my previous post:
if (lockList.containsKey(key)) { Object value = lockList.get(key); [B]...[/B] }
I called wait() inside a synchronised block similar to your second solution (otherwise wait() would have thrown IllegalMonitorStateException).

My post was merely a pointer to get people thinking, and your second solution was very close to what I've done
Object value = lockList.get(key); while (value != null) { RecordLock recordLock = (RecordLock) value; // Check if caller already owns the lock; if so silently return ... // Check for deadlock (is the owner also waiting for me?) ... // Otherwise, wait on the record lock object... synchronized (recordLock.getLock()) { try { recordLock.getLock().wait(); } catch (InterruptedException ie) { } } value = lockList.get(key); } // Waiting is over... Lock the record if it still exists ...
And like Andrew said, unused RecordLock object will be slowly discarded by the garbage collector (after unlocking I don't keep them in the lockList anymore).

Well, I had 17 classes/interfaces in total. Out of these; 3 were exception classes.

I had plenty of inner-classes and anonymous classes though (especially ActionListeners for GUI elements).

Hi Marcus,

I've solved the problem you've mentioned by not synchronising on the hashmap but using an already synchronised hashmap (by creating the hashmap with Collections.synchronizedMap()). This type of hashmap guarantees individual containsKey/get/put method calls are thread-safe (serialised).

Have a look at my locking design at this thread.

Tebrikler Baris,

... And you were so worried earlier