Attila J�borszki

Greenhorn
+ Follow
since Oct 11, 2008
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Attila J�borszki

I lost 16 points on GUI, probably because I hard coded a lot of info about the database (number of record fields, record field names, ...) for the GUI on the client side.

But I am very happy, thank you all very much for the help.
11 years ago
Hi,

I have another GUI problem:

I pack and set visible my GUI.
It appears on the screen ...
I immediately try to resize it and its window is not updated ...
after I release its window corner and try to resize it again ... it is OK, it works

Usually this happens if I try to resize it immediately after it is displayed but not all the time.

But if I wait until a tool tip is displayed and I try to resize it after that ... it is OK.

Any idea?

Thanks,
Attila
[ December 14, 2008: Message edited by: Attila J�borszki ]
I ran into a similar problem also.

You should remove the "extends DB" from RemoteDB declaration.
This is needed if you do not want to change the DB interface. I guess, Sun does not allow to change its interface.

The problem is that the methods of the class, you want to send through RMI, have to be declared throwing RemoteException. If you leave "extends DB" in the declaration of RemoteDB, you should change methods of DB to throwing RemoteException.

You should imagine RemoteDB as a wrapper class for DB. Methods of RemoteDB should throw RemoteException. The client will see the remote database through RemoteDB.

And I think, you should use a 3rd interface for Controller on the client side to hide the difference between RemoteDB and DB.


I guess, you also used the Monkhouse book ... It is a trick in this book that Monkhouse defined his DBClient methods throwing IOException. In this way, the DBClient methods can throw RemoteException also because RemoteException is an IOException. So, he could insert "extends DBClient" into the declaration of DvdDatabaseRemote. But this solution works only if the methods in Sun provided interface (DBMain, I guess) throw RemoteException or IOException.

Regards,
Attila
[ December 07, 2008: Message edited by: Attila J�borszki ]
SwingUtilities.invokeLater() works! I put the initDefault methods into it and it works.

I used a SUN example how to implement MVC. In this example, these initDefault methods are called after the GUI is assembled and before it is set visible. But in my implementation this does not work ... I have to call these methods after the GUI is set visible.

Thanks for the help!

Originally posted by Alecsandru Cocarla:
I saw you have another question about your application freezing because of a textfield. Are you sure it's not from the same problem?



It is the same problem ... At first time, I found this insertString issue but later I realized that the ActionListener belongs to this textField is called when the insertString is executed, this ActionListener updates the Model belongs to this View, but the Model warns the View that the content of its variable changed ... the View executes a check if the start button can be enabled because of this change ... so I finally got to this setEnabled method ... and I got stuck here ...
Hello,

I have a bad feeling that dead lock can occur in my client GUI. I realized that sometimes my app gets frozen when displaying its main window (JFrame). I was able to trek the problem till a setEnabled method is called on a JButton. My app gets frozen at this point. I use a lot of ActionListener and PropertyChangeListener ...

I realized that if I put a Thread.sleep(40) between displaying my main window and filling it up with default values ... this frozen does not occur.

So, should I prepare my GUI with considering some kind of concurrency in Swing components? Should I lock my buttons, textFields ... before I use it?

Thanks,
Attila
[ December 06, 2008: Message edited by: Attila J�borszki ]
Hello,

I tried this idea: overriding the method insertString and it seems to work in general, BUT ...

sometimes my app gets frozen in

super.insertString(offset,str,a);


the parameters looks OK,

offset = 0
str = a valid string
a = null


Have you got any idea what could be the problem?

Thanks,
Attila

Originally posted by Roberto Perillo:
Champ, all objects that will be sent from an RMI server to the client (and vice-versa) must implement the java.io.Serializable interface.



Thanks for the help, but a different issue caused the exception in my case.

In the Monkhouse book, the remote db class extends the original interface DBClient also:

public interface DvdDatabaseRemote extends Remote, DBClient {

But in my case, this does not work because of the introduction of some new exceptions in the database implementation.

In may case, this row looks like only

public interface DvdDatabaseRemote extends Remote {

Monkhouse could use his DvdDatabaseRemote as DBClient in the client side, but I can not do that ... but I tried to force it out ... and this was the problem ... now it works ...

Thanks,
Attila
Hello,

As I can see, I did everything similar to the method described in the Monkhouse book. I use RMI with RMI factory pattern.

During the tests, I can start the server and the client can connect to it but when I would like to instantiate my DBMain on the client side, I get a NotSerializableEception can be seen below.

What can be the problem?

Thanks,
Attila

java.rmi.UnmarshalException: error unmarshalling return; nested exception is:
java.io.WriteAbortedException: writing aborted; java.io.NotSerializableE
xception: suncertify.db.Data
at sun.rmi.server.UnicastRef.invoke(Unknown Source)
at java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(Unkn
own Source)
at java.rmi.server.RemoteObjectInvocationHandler.invoke(Unknown Source)
at suncertify.remote.$Proxy0.getDBMain(Unknown Source)
at suncertify.remote.ContractorDBConnector.getRemote(ContractorDBConnect
or.java:53)
Originally posted by Liviu Carausu:

If the specified record is already locked by a different client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.



Thanks Liviu!

My specification of the lock method says that

If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.

According to my specification, I could say that the deadlock is the required functioning if the same thread locks the same record more times ...
[ November 11, 2008: Message edited by: Attila J�borszki ]
Hello,

What do you think, is it a problem if a client locking the same record twice causes deadlock? Should I handle this situation: a client wants to lock a record twice or more?

Or is it enough if I mention in the decisions doc and in the javadoc comments that this situation will cause deadlock?

If I should handle locking the same record twice or more by the same client, should I count the locks on a record to ensure that the client unlocks all locks before the other client can access the record?

In "SCJD Exam with J2SE 5" book example, locks on a record are not counted and a client locking the same record twice or more can cause deadlock.

Thanks,
Attila

Originally posted by Andrew Monkhouse:
So leaving the record locked is fine, as long as you notify any clients waiting on the thread that they should try to get the lock again (at which point they should get a RecordNotFoundException or similar).



Hi,

There is a rule for the lock method: "If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked."

If I leave the deleted record locked and I notify the waiting clients that they should try to get the lock again, I break the second part (no CPU cycles until the record is unlocked) of this rule ...

Or is this pedantry only and does not Sun take this rule so rigorously?

Attila
[ October 16, 2008: Message edited by: Attila J�borszki ]

Do you also think that the deleteRecord should not unlock the record ?
Then the unlockRecord will fail in any case after the record is deleted.
Calling unlock on a deleted record is a nonsens in my opinion. What do you think ?



Hello,

I think this is your decision.

My interface description says only that a RecordNotFound exception should be thrown if calling the unlock method on a (locked or unlocked) deleted record, but it says nothing about what should happen with the lock on a locked deleted record.

Maybe the lock should remain on that locked deleted recored ... but this idea should not break the rule: the lock method should drop a RecordNotFound on a (locked or unlocked) deleted recored ...

But you should document this decision.

Attila
[ October 11, 2008: Message edited by: Attila J�borszki ]