wood burning stoves 2.0*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes  Can the ClientConnection be used for transaction,exception handling Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark " Can the ClientConnection be used for transaction,exception handling" Watch " Can the ClientConnection be used for transaction,exception handling" New topic
Author

Can the ClientConnection be used for transaction,exception handling

HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Note that this ISN't required by the cert. I am just testing the waters to see how easy it is to implement.
By transactions , I meant as applied to databases, where you can have transactions commit changes, rollback if necessary.
( Say your database didn't have a way of handling these and you needed an extra layer of control, so you need to write your own ? )
I think essentially what I am asking is can ClientConnection and DatabaseConnectionManager be merged , seeing as the acquire/update/release protocol fits nicely here? And you don't have to manage threads at the database end to see who is allowed to do what!
Say , that you have implemented view Customer Bookings functionality and view Flight Availability in your app (not required by the cert, but it's all about learning - here I can see how threads behave). By making the Data class abstract and extending it, and having an AbstractFactory in front I was able to re-use the given classes, just by adding context to the signatures.
You will have the added headache that when recording the Customer Booking the Flight Availability count is decremented simultaneously.(but perhaps your clients pay well for this feature creep).
Now the LockManager provides the required isolation to updates. For managing transactions, TransactionManager which will have methods like begin(), rollback(), commit() , finish() ..

I think the question summarised is :
Is the ClientConnection Object the same object that is invoked repeatedly by a customer making bookings in the same session ,or to explain better ,if lock and then unlock, can be called from the GUI can you still be sure that it is the same client or does RMI give you a new object.
If the answer is yes, then I think I can use the ClientConnection to manage transactions.
If you've read this far thanks for considering this. If anyone can see the wood for the trees...help.
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Searching past posts it looks as though RMI will give you a new object each time...so no go..
I think I am confusing this with a jdbc type Connection object which is a session type object.
Thanks
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
But it is... it's a "go" rather than a "no go". For a given client, there is a single server-side Connection and a single client-side Connection stub for the duration of the session. This Connection could be made to do the very same things that a JDBC Connection does, including supporting transactions.
Of course, when a given client requests a new Connection from the ConnectionFactory, you do get a new object. This is no different from JDBC, where acquiring a new Connection will give you a new, independent transaction (managed environments like EJB containers excepted).
I know you stated this up front, but for the benefit of anyone skimming through this thread -- this is absolutely not a requirement for the assignment!
- Peter
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks. I was thinking of multiple-transactions which you'd expect a true client-server to have a "persistent" connection between 2 machines and be able to track clients across individual requests.
Say the app offered multiple bookings, flight with hotel , and certain combinations had more incentives to the user than others. You'd want to ensure that there was availability upfront but would want to commit all or nothing, and wouldn't want the user to go through the whole shooting match.
But with the way RMI gives a new object each request means the developer would have to implement true client-server behaviour.
Is there a standard design pattern that one could use with RMI.
Again, this isn't a requirement for the certification.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by HS Thomas:
Thanks. I was thinking of multiple-transactions which you'd expect a true client-server to have a "persistent" connection between 2 machines and be able to track clients across individual requests.
Let's state up front that this is... oh well, I suppose we covered that now
Yes, and yes, you can do all that. Just hold on to your database Connection stub after use! Of course you would have to have commit() and rollback() methods, and all the requisite plumbing on the database server.
Really, there is no difference between this Connection object with hypothetical transaction support in the FBN database server, and the JDBC Connection you get from a "real" database server. In a real database, too, there will be some server-side object (or at least data) associated with your session. And when you let go of your Connection, that object or data is lost forever too.
Or am I misunderstanding you?
- Peter
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Just hold on to your database Connection stub after use!

That simple !
Or am I misunderstanding you?

No, that just about answers the question.
Let's see if I've got it right.
Reusable Connection ('cos holding on to stub), that extends UnicastRemoteObject and implements the RemoteData interface.
RemoteDataFactory (on client ) looks up and keeps re-usable stub to Connection > creates new instance of RemoteDataImpl > which creates new instances of TransactionManager and Lock Manager . The Connection has methods to acquire and release locks and begin,commit or rollback and end transactions. As long as the same stub is re-used ,the Connection instance is reused and hence so is the TransactionManager instance which knows the status of the Transaction.
Does this look correct ?
Thanks
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Correction. The Connection has methods to call corresponding aquire,release methods on the LockManager and transaction-type methods on the TransactionManager. Is this the general idea?
Must emphasize again. THIS IS NOT REQUIRED FOR THE ASSIGNMENT. This just helps me get a clearer idea of the role that this Connection object can take on , just using RMI.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Looks fine to me HS.
- Peter
HS Thomas
Ranch Hand

Joined: May 15, 2002
Posts: 3404
Thanks Peter for your help
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Can the ClientConnection be used for transaction,exception handling
 
Similar Threads
Server approach - I think I might be missing something
3 client types for locking
Final review - PLEASE READ
How many db fiels in the assignment?
How to control the transaction with external system?