Gareth Llewellyn

+ Follow
since Nov 16, 2005
Merit badge: grant badges
For More
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 Gareth Llewellyn

Personally, I feel they are never going to fail you for showing your mastery of JTable TableColumn objects and TableModels. I've made my smoking column a checkbox by overriding getColumnClass in my extension of AbstractTableModel, I think this only adds to the usability rather than increases my chance of failing.
Create a new interface, say Database.
Have Data class implement DB and Database.
Have DBRemote interface extend Remote and Database.
Have DBRemoteAdapter class extend UnicastRemoteObject and implement DBRemote.

Database declares all of the methods in DB plus any new ones, such as your multiunlock method. It should throw the lowest common denominator Exception class, which you will probably have as IOException (RemoteException extends this).

Any class wishing to talk to a database, whether it is remote or local, calls methods on an object of class Database. This solves many problems, such as Adapter pattern use of local / remote Data object through a unified interface, plus allows you to extend DB to include other much needed functionality.

Do NOT extend RuntimeException as you may have read elsewhere. Checked exceptions to the client all the way. LockManager should be a singleton, personally I also have a RMIRegistryService and a LogManager as singletons too.
The locking mechanism is wrapped around each critical part of DvdFileAccess, which I guess is similar if not the same as DataFileAccess.

private static ReadWriteLock recordNumbersLock
= new ReentrantReadWriteLock();

Its thread safe. The class doesn't need to be a singleton (LockManager and LogManager style classes are another matter...)

You end up making the whole class thread safe anyway by implementing a lock manager / mechanism on the Data class that uses DvdFileAccess / DataFileAccess.

Personally I didnt use the locking mechanism he employed, but a threadsafe record number / file location map instead:

private Map recordNumberFileLocationMap = Collections.synchronizedMap(new HashMap());
Given my swing gui is operating in the event dispatching thread, and my database model is operating in the main thread, I quickly found the gui was sluggish on repainting during long database operations (such as retrieving all records, reg exp pattern matching vs record contents etc.). While my data layer has a cache of record number / file location, the gui is still affected during these time consuming operations. To get round this I simply off loaded time consuming tasks to a SwingWorker implementation, overriding construct() and finish() methods. Given SwingWorker isnt part of the API, but rather a neat helper described by the Swing tutorial, am I even allowed to include this code in my assignment? Do I have to strip this great stuff out and go back to poor performance? My view is calling back into my controller which in turn manipulates my model. Would I have to add some home grown threading support into the controller to handle the time consuming tasks?

Thoughts and opinions welcomed.

To improve the performance (especially repainting) of your Swing GUI, y
okay, so I've answered my own question, but RemoteException is not broader than the base DBClient's thrown IOException - it's a child of IOException, so the code will compile and we are not obliged to declare RemoteException explicity.
Sorry to waste space on the forum!

Question for Andrew Monkhouse:
In SCJD Exam with J2SE 5, Second Edition

By implementing DvdDatabaseRemote, the DvdDatabaseImpl class is required to implement its super interface, DBClient. Trouble is, DvdDatabaseImpl throws new and broader checked exceptions than the interface its implementing - which is not allowed - and indeed the compiler prevents.

How can DvdDatabaseImpl implement DvdDatabaseRemote (and therefore DBClient) and still throw the RemoteExceptions required by the Remote interface?

Naturally we are trying to achieve some factory class (in the book's case, individual DvdConnector classes rather than a factory) returning DBClient objects. But given the above problem, DvdDatabaseImpl CAN'T implement DBClient...
...I guess I must be missing something in the implementation.
I guess thats what the optional <description> element should be used for to convey this info from Bean Provider to App Assembler etc. As the DD is the only REQUIRED piece of "documentation" delivered by the Bean Provider, that is all you could count on. But the Bean Provider may not bother telling you the relevant method info, and thus you are right, formal Bean documentation would have to accompany the ejb jar to document its inter-bean dependencies.
So its...

Remote checked Exceptions:
(subclasses of java.rmi.RemoteException)

Local unchecked Exceptions:
(subclasses of javax.ejb.EJBException)
[ November 17, 2005: Message edited by: Gareth Llewellyn ]
"If a Bean A method calls a Bean B method, the app assembler won't know unless he looks into the code and sees that method call"

Actually, the App Assembler will know because the Bean Provider will have to have an ejb-ref in the DD so he can do a JNDI lookup to Bean B from Bean A. They App Assembler and Deployer will take care of the correct bindings within the J2EE app.
Okay, this time I have a mock exam question concerned with Exceptions.
The debate I have is with the interface hierarchy quoted in the question:

If a remote client in a transaction context invokes a business method on a bean with container-managed transaction (the business method has transaction attribute as either Required, Mandatory, and Supports) and the bean throws a non-application exception, the transaction is marked for rollback. The client then receives javax.transaction.TransactionRolledbackException (subclass of java.rmi.RemoteException) which indicates that the transaction has definitely been marked for rollback.

Whats the problem? Well HFEJB quotes TransactionRolledbackException as deriving from javax.ejb NOT javax.transaction. Which is correct?
(The following exam question appears from and is not taken from the real SCBCD exam set.)

What I need is an expert opinion on the why option number 5 is correct. Why can't an EJB class have a package structure? Head First EJB even suggests a package structure is possible given the contents of an ejb jar are the META-INF directory AND the PACKAGE DIRECTORIES. Is this question wrong?? What's all this talk of a security hole? That certainly didn't get mentioned in HFEJB!

Identify correct programming restrictions that a Bean provider must follow to ensure that the enterprise bean is portable and can be deployed in any compliant EJB 2.0 Container. [Select all correct answers]

1 The enterprise bean cannot define read and write to static fields.
2 The enterprise bean cannot make use of the Java Swing API.
3 The enterprise bean cannot make use of interfaces to define business methods.
4 The enterprise bean cannot make use of the Sun JavaMail API.
5 The enterprise bean must not attempt to define a class in a package.

Answers 1, 2 and 5 are correct.

Answer 1 is correct. This rule is required to ensure consistent runtime semantics because while some EJB Containers may use a single JVM to execute all enterprise bean's instances, others may distribute the instances across multiple JVMs.

Answer 2 is correct. Most servers do not allow direct interaction between an application program and a keyboard/display attached to the server system.

Answer 5 is correct. This function is reserved for the EJB Container. Allowing the enterprise bean to perform this function would create a security hole.

Answer 3 is incorrect. It is possible to create an interface and implement the interface to make available in the enterprise bean business method.

Answer 4 is incorrect. The enterprise bean can make use of the JavaMail API.