Tomas Klubal

The sentence fom the book is not quite correct as you can have 2 types of persistent fields (according to the spec 2.1.1; 4.3): state-field or association-field.
The difference between those two is that association field points to another entity (type is the abstract
schema type of the related entity) and the state field does not (it is just some value of type valid for persistent fields).

Example for entities "Person p" and "Account a" is:
state-field: p.age
association-field: p.account

Except specs I have also read Mastering EJB3 (few year ago) and done Enthuware tests. I have also used OpenEJB (only in unit tests) for testing and clarification of the concepts.

From top of my head I remember at least three.
1) some references to the life cycle callbacks list pre-construct and post-destroy as callback methods instead of post-construct and pre-destroy
2) listener binding method examples have missing method element and lists directly his children instead (method-name,...)
3) JPA spec. states that composite primary key class must be serializable however at least one example shows implementation of PK class that is not Serializable. (JPA spec 9.1.33)

Hi ranchers,
I have passed SCBCD 5.0 today

My advice is: Read the EJB specs. Even though they are sometimes boring (there is also few mistakes) they are also interesting.

Tomas

Where to start?

Security context is term referring to security-related data (i.e. Principals, roles) that are used for invocation of EJBs (and other technologies are using same term as well). How it is implemented, what it contains and whether you actually have some SecurityContext class is container specific.

As per EJB spec.

Accessing resource managers and enterprise beans is disallowed in the session bean methods
for which the container does not have a meaningful transaction context and/or client security.

(similar applies to MDB)

Therefore in methods where it is meaningful to have a security context, security identity is either propagated from caller (even from other technologies) or if there is no identity to propagate some default one is used.
So if user does not authenticate default "security context" is used and when you ask for caller identity vendor specific representation of the UNAUTHENTICATED identity is returned (guest, anonymous or something similar).

Further you can use @RunAs annotation (or run-as in DD) to specify identity that will be passed to other components.

The last option 3. is correct even for stand alone client. You can use no arg constructor for initial context if you supply jndi.properties and there is no need to narrow if what you retieve is a business interface.

First: The firts quote from Zaikins quide is not correct as you can call these methods also from SFSB (CMTD) Callbacks, synchronization methods (afterBegin, beforeCompletition,afterCompletition); SLSB and MDB Timeouts and @AroundInvoke.

Second: You always need security context otherwise you get java.lang.IllegalStateException however having security context does not mean you have security identity (i.e. client was not authenticated because he called EJB anonymously or these methods were called in Timeout method)

Hm. If you change option 3. to use

template = (Template)Context.lookup("java:comp/env/ejb/template");

then options 1. and 2. are no longer correct unless you change them as well.

Option 1.
... Template template = (Template)context.lookup("ejb/template");
Option 2.
@EJB(name="ejb/template") Template template;

I passed SCJD with 386/400. The following is the breakup..

General Con: 100 86
Documentation: 70 70
OOD: 30 30
GUI: 40 40
Locking: 80 80
Data Store: 40 40
Network Server: 40 40

I believe that I loss some of the points in general considerations due to the fact I had couple of too long anonymous classes.

Originally posted by CP Cahill:
Wouldn't it be best to have a lock for the RandomAccessFile object and enforce a design rule that programmers must acquire this lock before using the object in any way?

Yes,
that's my solution. Instance of the RandomAccessFile is used as a lock object and every access to it is synchronized.

Originally posted by Jonathan Wolter:
In many exam problems, we may assume only one "Server application" -- and if you choose, one thread - is accessing the database file. Do you have an implementation that suggests this thread safety issue is a problem? I must be missing something...

Jonathan

I have implementation that uses multiple threads accessing the same instance of the RandomAccessFile.

For instance while thread A is reading all records to perform search on them, thread B is trying to read (or update or delete) particular record.

I have experienced following:

Thread-B sets the file pointer to ie. 192 and is sliced out

Thread-A thread calls length() and inside this operation moves the file pointer to the end of the file and is sliced out before it can return file pointer to the original position and finish the length() operation.

Thread-B tries to read from the incorect position set by Thread-A and throws EOFException.

Thread-A finishes the length() method by setting the file pointer to the original position

Originally posted by Musab Al-Rawi:
Hi,
One solution that I can think of is opening a random access file in each method separately. That would solve closing the file and the unsynchronized length().

My solution is to synchronize on the random access file when calling length and assign the length to the local variable before iterating through all records during search.

Hi,
I think that it might be interesting for other ranchers to know that RandomAccessFile.length() is not thread save. File pointer is moved during this operation before it is set back to the original position. I have experienced EOFExceptions when retrieving all records even I had seek/read and seek/write operations synchronized.

See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4823133 for details.

Regards,

Originally posted by Alex Belisle Turcot:
Hi,

I did not see this example, just a quick idea, could it be that he's using some WeakHashMap/WeakReferences ?

regards,
Alex

Well, he does not and I doubt it would help in any way. I have found one thread that describes the same problem in greater detail and without any solution.
B&S: Locking dilema

Rehards,
Tomas

Hi Ranchers,
I am a bit confused about the example for the "Multiple Notification Objects" in Andrews book.

This example never removes the dvdLock (per record lock) from the reservations. This means that once the record is reserved it stays in the reservations map together with the database object for ever (even if the lock is released ). There is not problem regarding the locking as every unlock method sets reserver in the dvdLock to null so the record is free for use, but map grows bigger and bigger until its size is equal to the number of records and it never changes until the program is restarted.

I was not able to figure out how and where to identify the situation where dvdLock can be completele removed from the reservations.

Do you have any ideas?

Regards,
Tomas