FAQ of Assignment 1 of comp6231
> 1) is each e trader application independent and located in
> independent host, or the server appliction contains all traders' > objects running in one host and exchange their items among these > objects based on the client's invoke. yes, each e-trader is an independent server, handling a particular item. The buying or selling happens between pairs of them. They may run in different hosts. However, if you use different RMI "registery" properly they can run in same host. Refer to my web site about RMI registery in RMI-FAQ 18.
> 2) if each e trader located in the different host, do we have to use
> socket program to exchange their items among these e traders. No, you are supposed to use RMI. > 3) About changing the price, do we need use a timer or we make the
> rule to change the price, for exampel, after sell 5 items, the price > could change.Yes, you need a timer for each item. In the simplest case, each e-trader handles exactly one item, so, each e-trader has its own timer to setup a timer-handler which will update price after fixed amount time periodically. You can find java Timer function in www.sun.com or elsewhere. If you guys find difficulty in using timer, let me know. > 4) after a e trader buy the items from other traders, can he sell
> this buying item, or just keep this item and finally print them on > the report. what I concerns is if the e trader is allowed to sell the > other kinds of items, it is hard to located its role. finally, the > client might get confused.> yes or no. This assignment is already too complicated for many of you to finish. And for this particular point, you can simplify yourself by assuming each e-trader only sells his own item. However, there is no limit for you to allow e-trader to re-sell whatever it buys.
> 1. Do the e-traders have to run on different hosts? I mean, could I > implement several e-trader objects in one application, and let one > e-trader locally invokes another one when buy/sell items? And the RMI > techonology will be used only between clients and servers, but not > between two servers. NO! Because the purpose of assignment is to ask you to realize the difference between distributed system and traditional client-server architecture.The buying and selling is between independent e-traders and each of them is an independent server. So, the implication is that e-trader may need invoke RMI call between them when client invoke RMI "buyItem" call to one of them. a.) client---> invoke (RMI buyitem) to e-trader1;b.) e-trader1 invoke (RMI sellItem) to e-trader2c.) e-trader1 receives return of (RMI sellItem) from e-trader2 and return(RMI buyItem) to client.
> > 2. I am a bit confused about the interfaces given in the assignment. > Should all the three interfaces be called by the clients? If clients > will call sellItem(item, quantity), do you mean that one e-trader > could initiatively sell something to another e-trader? I don't think > this is reasonable. Because if so, how do I know which e-trader I > will sell to? The interface doesn't have such a parameter. So I > suppose that the interface sellItem() will be used only between two > e-traders. Do I get the point?> Yes. One reasonalb design is to assume "buyItem" can be called by client and "sellItem" is only used between servers or e-traders. Of course "report" is used by client, too. >First, Where can we get these data source.
Do we create them randomly? And what are
>these Items?
You
might make your own assumptions about a small business environment, say a
market or
something similar, in which you can grab the names and setup the corresponding
prices,
just up to your own convenience. Of course you can make non-sense names/prices
and use
them, but relating those to something in the real world will make your thinking
easier.
>Second, the items' price change periodly, how to decide this time?
What
'change periodly' means here is that the prices are
not permanently fixed all the
time, therefore you need to find a way to change it, such as changing it
randomly (as
suggested in the problem description). This in fact also helps you to see the
differences
that your resulted e-trading system would create, say druing
debugging and testing.
>Third, do we need to save the data to
file from server after we shut down the server?
No.
Read the problem description carefully and you will find that all data should
be
stored in memory. In assignment 1 there is no fault-handling issue. Therefore
you don't
have to consider stable storage to save your data. Also, DO NOT use database to
resolve
data race problem, because by doing so you are actually avoiding the problem by
leaving
the responsibility to the DBMS.
>Fourth, do we need to maintain clients¨ log file or user file? If
not, how to uarantee
the security? If so, the requirement is not mentioned.
There
is no security or description issue. Simply assume that all RMI calls are
secured
by the underlying platform and there is no intrusion or monitoring behide. And leave all
fault tolerance issues later on in doing your project.
>Last of all, can you tell me what you need in report?
Keep an eye on the link 'Tips and Suggestions from POD' that you can find from the course
website. We will work out a guide about how to prepare your report shortly and will
distribute it to all of you.
what is good and bad of assignment 1
1. You must strictly follow the interface given by professor.
2. You must run at least two independent servers to be able to sell and buy. If you register all your server "instance" under the SAME REGISTRY NAME, then how can you make difference of different servers? No. You cannot! So, hard coding server names doesn't mean you use one name for all server. See 6 below.
3. By using multiple locks, you can push "synchronization" into fine-grained level to improve performance.
For example, in side "buyItem"
...
synchronized (buyLock)
{
//local checking etc. setup remote object reference
synchronized(sellLock)
{
//update your balance according to return result.etc.
}
}
This separate lock will allow one buy thread and one sell thread running at same time in our server.
/////////////////////////////////////////
And the following comment is NOT true because the total balance maybe inconsistent with summation of detailed transaction records if you have not synchronized "printReport" with other operations.
{{And if you observe carefully the "printReport" is a readonly operation which requires no synchronization at all.}}===>Wrong!!!
//////////////
However, you must realize this is only conceptual level coding. If your buy and sell try to modify some common variables, you still need to place a common lock for buying and selling. This scheme might be useful in future assignment when your "buyLock" do the available money checking and "sellLock" only updates quantity balance. (Why do we need this? Maybe it is useful for a transaction in A2. )
4. Question: Can "synchronized" method inheritable?
Answer: As far as I know it is not because "synchronize" is actually not part of function signature and cannot be automatically inherited. Besides the "synchronized" only works for "object-level" which means when you are using a parent object and a child object the synchronization is purely two separate thing.
5.Question: Can the above "nested lock" prevent deadlock from happening?
Answer: Yes and no. Somebody says the "nested-lock" is a typical pattern of deadlock. You must be very careful to make sure the scope of "buyLock" and "sellLock" will NOT OVERLAP. For example, you make "sellLock=this" will overlap with "buyLock" and will create deadlock.
6. How can I run multiple servers in same host?
Simple. Just use command line parameter to let server register under different registry.
7. "Synchronized" is only "object-level" which means different objects shares no common synchronization at all.
For example, in Timer's TimerTask's run method we try to synchronize the "changing price" method like this:
void run()
{
synchronized(this) //this "this" refers to TimerTask not our DetImplement class object
{
//change price of E-trader
}
}
This issue is quite subtle and we can discuss in tutorial.
8. In the testing program you may create a bunch of testing threads and if they don't use "join" your main thread may end before them.
...
PairTransferThread t0[]=new
PairTransferThread[RunningThreadNumber];
PairTransferThread t1[]=new PairTransferThread[RunningThreadNumber];
for (int i=0; i<RunningThreadNumber;
i++)
{
t0[i]=new PairTransferThread(account0,account1, 50);
t0[i].start();
t1[i]=new PairTransferThread(account1,account0, 50);
t1[i].start();
}
...
for (int i=0; i<RunningThreadNumber;
i++)
{
t0[i].join(); //================>You need them to run till end
t1[i].join(); //================>You need them to run till end
}
9. When marking, I feel some students don't exactly know what to analysis. And here is a perfect example of what to do. We know the interface given by professor has no price as parameter. Then do we have to consider about insufficient balance when buying? One student points out that his/her assumption is negative balance is acceptable because you can only know the selling price when the other etrader replies your request. So, for consideration of performance we can assume negative balance is acceptable. This is a very good consideration of performance and this is a good practice of analysis.
10. Another bad example is that one student uses a complex type, namely the ETrader, as return type of "printReport". This is not a good design because the class may contain many more data than we need. Therefore it is inefficient. What's more, it is difficult to scale or migrate. Taking CORBA as an example, you will realize that it is hard to use this in A2.