Win a copy of Rust Web Development this week in the Other Languages forum!

Xavier Fabreguettes

Greenhorn
+ Follow
since Jul 17, 2003
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 Xavier Fabreguettes

Just to confirm, I woul rather use a cart to store all pending itienraries and have a cehckout screen or a pay screen where you can pay for everything in your cart. Once payment made, the cart should be emptied. The only problem is that, the way I read the use cases, payment seems to be triggered immediately after an itinerary is prepared. At the same time, the pay use case seems to be available to users directly (not as an inclusion of amother use case).

In addition, how a change is triggered? What do you apply it on? It only makes sense if you have a cart with pending (unpaid) itineraries...
What should happen to bookings once they are paid for? Should they will accessible to users? (will be accessible of course for reporting and maybe if an history page is added to the site). IMO no, but happy to discuss.

Thanks,

Xavier
Ranchers,

A probably trivial question for you, but I'm not too sure how to understand the paying and changing processes. As far as I understand the PrepareItinerary use case, as soon as your mind is made up on an itinerary, the pay use case is invoked, which would mean that instead of having a shopping cart and proceeding to check out whenever you feel like it, you are immediately taken to the check out (taken from prepare use case, end of Basic Flow: "System sends the priced itinerary to Pay for Itinerary Use Case"). In this case, the itinerary is immediately paid (unless the payment is not authorised). I don't see as an aternative flow the possibility to carry on browsing by deferring the payment time once an itinerary is selected. Am I missing something?

This would imply the following:
- no need for a shopping cart
- when you change itinerary, the change applies to an itinerary that has already been paid. how payments are reconciled? Because it is one thing to delete the segment from the itinerary, but what becomes of the corresponding payment that was debited from the card?

But at the same time, why is not the Pay use case an inclusion of pricing use case (user can invoke it as standonle according to global use case diagram)?

Could somebody please clarify a bit these points? Xavier

Many thanks,

Exception class extends java.io.Serializable. There is no need to implement Remote interface.



Makes sense. Forgot to check, it should have put me on the right track! Thanks for your help.

Xavier
Hi,

I was wondering about what happens when you have a client application (plain java class) invoking a method against an EJB via RMI.

Say that the Remote interface is something like



where MyException is an application exception written by the bean provider (hence packaged up in the same jar as the bean itself).

For this invocation to work successfully, do specific constraints apply to MyException? (i.e. implementing Remote or Serializable)?

Thanks for your help.
Thank you Joyce for the quick and detailed answer.
Xavier
Hi All,
In the Headfirst book, it is said that for MDBs you are not allowed to:-
- attempt to start a BMT transaction from within another one (i.e. have 2 nested userTransaction.begin() calls)
- attempt to return from a method before the BMT transaction is finsished (i.e. return before calling userTransaction.commit() (or rollback())
I'm OK with that but my question is what would happen if you tried to to what is described above? The book just says not to do it but does not explain what the consequence would be. Would an IllegalStateException be thrown?
Thanks,
Xavier
Andrew,
Thanks for your reply. Yes, I totally agree with your 2nd paragraph, what I meant was that as you are sure taht nobody else is in a position to modify the DB when your thread is about to do it, CONSEQUENTLY the updation will be thread safe. I was aware that the locking mechanism is not a customised way to implement thread safety.
I do use a singleton and have therefore only one instance of the database. The thing if that initially I had made my read method synchronized and my update one not (because of the lock menchanism), but I can see now that having my update method synchronized should be enough. Is preferable to synchronize on the file object (RAF or FileChannel) or to have the whole update method synchronized?
Once again, thanks for your help.
Kind regards,
Xavier
Hi,
My assignment is the contractors one. I want to perform my reads without caching and would like you to clarify a few points about the impact multithreading could have on my approach. I am not worried about writing to the DB as the locking process is here to take care of concurrent updates. What I would like to know is when performing a read, how can I guarantee that between the moment I position my cursor (for either a RandomAccessFile or a FileChannel) and the moment I read, no other thread is going to change the cursor's position by either reading or writing another record? I understand that at least if I use FileChannel, the actual read won't be messed up with i.e. no thread is going to change the cursor between the moments the first byte and the last byte I am interested in are read. My concern is how to be sure that between the 2 lines of code in my read function:
- position cursor
- read record
the 'ownership' of the file is not going to be handed over?
When using locks for update, we can set up the cursor location and carry out the update within the same block, knowing that no other thread is going to update the record as all updates apply the same locking mechanism. However, I think that a read could possibly interfere with the update as it doesn't use the same mechanism. I am not sure that synchronizing the read function or synchronizing on the FileChannel (or underlying RandomAccessFile) would achieve anything as, because of the locking mechanism itself, writing records doesn't require synchronizing anything. Any idea anybody? Please let me know if I am missing anything very obvious or - more likely - if I didn't understand correctly how multithreading works.
If possible, I would really like to avoid using caches: I don't want to start again the debate about caching v. no caching, I just want to know if there is a solution to my problem.
Thanks a lot for your help.
Xavier
Good question! I don't really know as it is for the SCJD assignment and the specs are not specific enough (BTW I posted this message here and not in the SCJD forum as only few people are using sockets instead of RMI). I suppose you don't expect a lot of clients, maybe 20 (wild guess!).
In fact, what I'm interested in would be general pros and cons about the 2 options and also any idea about how to maintain the connection alive if we want to (the code sample with the infinite loop is certainly far from efficient but I don't see other ways to do it).
Cheers,
Xavier
18 years ago
Hi,
I am trying to develop a multi-threaded server that will get some customized objects from a client via ObjectInputstream, spawn a thread per connection, process the data, and then back another customised object to the client via the same connection.
Considering that a client can send several requests during the same session (but not together, just one request at a time), I would like your opinions on the best approach:
1) I treat each request as if it was independent i.e. on receiving the request, a new socket connection is started and a client handler thread is spawned on the server side to handle the request. Once the response is sent back to the client, the connection is closed and the server is ready to handle of subsequent requests from the same client as if they were coming from a different client. [note the processing done on the server-side is not client dependent]
2) Same thing but once the first response is sent back to the client, I keep the connection alive to service subsequent requests coming from the same client. This approach avoids the overhead of creating a new connection for each requests but I am wondering about the cost of looping on the server side to see if request objects are coming in.
I would prefer 2) but it really depends on the way I hadnle the InputObjecttream. Indeed, if thought about using an infinite loop and keep doing things like:
// **** surrounding try/catch
// ois is my instance of ObjectInputStream
while (true) {
Object o = null;
try {
o = ois.readObject();
} catch (IOException e) {
continue;
}
try {
MyRequest req = (MyRequest) o;
MyResponse res = ... ; // processing
oos.writeObject(res);
} catch (EOFException e) {
// do something
}
}
This approach would consume quite a lot of processing time because of the infinite loop on the readObject() method.
My questions are:
- despite this, is approach #2 still better than #1 in terms of performance (the time processing of the loop is overall less than the processing of opening a connection everytime)?
- is there a better way to wait for new requests from the same client for approach #2, without consuming too many CPU cycles? Is there something similar to the classic
while (in.readLine() != null) {
...
}
used with InputStreamReader?

Many thanks for your help,
Xavier
18 years ago
Hi Mark,
thanks for your email. Your option might well work but this is not really the way I'd like to go as I'd prefer the sever threads to be transparent to the clients. What I am after is more a way to loop on readObject() functions a bit like we can do with Datastream using something like " while (in.readLine()) {...}".
Cheers,
xavier
Hi,
I am using sockets instead of RMI and I send across data using ObjectStream. For each client request, I establish a new connection, send the request, retrieve the response and then close the connection. This works fine and I am relatively happy with it.
However, I would like to know if people in a similar situation have done things that way or, instead, if they open a connection per client, service all the requests of the same client via this connection and then close the connection. I tried this approach initially but got errors when trying to use an infinite loop in the client (loop on read from stream). This is what is typically done with InputStream and I know it works (checked it), but there seems to be more to it when you use ObjectStream.
Any suggestion would be appreciated.
Cheers,
Xavier
Phil, Andrew,
Many thanks for your reply. I'd like to discuss further a couple of points with Philippe and whoever has suggestions to make about the questions I am raising here:

How did you implement your connection? At the moment, I open a stream from a client and send a request across to the server, carry out the query or update, send the response back to the client and then close the connection. If the client subsequently wants to submit another request, a new connection is established and the above is executed again. In this context I believe there is little need to keep a map of all cookies belonging to one specific connection handler (one client -> one client handler on server side) or is there? BTW have you found a way to keep the connection alive and therefore service several requests for the same client (I mean independent requests, I am not talking about multiple requests). I gave it a go a few weeks ago and got stuck because I was using an infinite loop on the client side, which did not seem to work very well. I know that it is easy with InputStream but it does not sound straightforward when using objectstream (which I do using serialized objects). Any tip?
Cheers,
Xavier
Dear members,
2 questions:
1) Has any of you (sucessfully) submitted you Contractors assignment with sockets instead of RMI? It is what I am using at the moment but it seems that almost everybody is referring to their RMI implementation. The specs mention though that either sockets of RMI can be used, and that should not be detrimental to the final mark as long as the choice is justified.
What is wrong with using sockets?
2) From reading previous threads, it seems that Sun is not too keen on input fields and much prefers JComboBox. Do you think that this also applies to the contractors assignment? I understand that if you choose a flight, the number of origins/destinations is limited but for contractors, the list may be much longer (and very long drop-down list are a fairly poor feature). You could also argue that people are maybe only going to remember only a part of the name (e.g. if it is "AAA, BBB & CCC"), which would mkae the CSR's job more difficult as they would have to visually scan the the list to find the contractor the customer is after (say "BBB" in the example above).
Another possibility would be to offer both combo boxes and textfields (which, to be honest, wouldn't require a big effort).
What are your views on this?

Many thanks for your help,
Xavier