Hi, I just received the project specifications for URLyBird and there are a few things that I would like to get cleared up before I start working on CRC cards/UML diagrams/use cases, etc...
My first questions have to do with the locking methods of the suncertify.db.DBMain interface. The interface contract for lock(int) says, "Locks a record so that it can only be updated or deleted by this client." From my understanding, DBMain (and its implementation class) are server-side, and I was planning to use this interface as a data access abstraction layer; I was going to have only one instance of a DBMain implementation (singleton pattern). However, if I do this, I do not see how I can lock a record for a specified client. So, my question is: is it implied that there is supposed to exist a separate DBMain instance on the server for each client connection?
My second question has to do with the update and delete methods. Does this look like a good idea?This way, a record MUST be locked for it to be updated.
Thirdly, there are no record numbers in the database file. Thus, I am thinking that I should "deserialize" the database and create a hashmap of HotelReservation objects, where the keys of the map are random and unique integers - these integers will be the record numbers. All database manipulation will be done in memory, and when the server is shut down, data will be written to disk. Good idea?
Last question: while the lock method is not supposed to lock against read operations, I am concerned about clients reading data while another client is in the midst of updating. This may result in the reading clients' receiving data that has been only half-updated. Is this something that I should be concerned about?
After doing some searching on the forum, I have found that I can use the thread ID to identify which client is doing the locking. The only caveat is that I must make [lock -> update/delete -> unlock] one atomic operation, which is fine, since it would be inefficient to have the client say "Lock record 5, now update it, now unlock it" in three calls. I think that I will just use the Facade pattern and have another interface with a safeUpdate method that will call lock, update, and unlock.
That answers my second question - I will actually keep lock() out of update(), and instead let another method include lock() and update() together.
As for the record numbers, I am still deciding on that.
I was thinking to actually use RMI. While I have _very_ little experience with RMI, the way it abstracts the networking seems perfect for this assignment; switching from networking to standalone mode just seems simple at a glance.
Because RMI does not let you choose which thread you get, I was thinking of using a third "business logic" layer that would have methods like book():This way, the same thread that locks the record is the thread that updates and unlocks it as well, and then I am free to use the thread ID to keep track of lock ownership.
About locking though... should the update/delete methods check to ensure that the client has locked the record???
Another question I have: what is a DuplicateKeyException supposed to do? The method signature in interface DBMain looks like this:
Can someone please clear this up? Thanks in advance. [ June 19, 2007: Message edited by: Cless Alvein ]
Can that really be the case? The "create" method returns the record number, which I presume to be the same thing as a key. I interpreted the contract of the "create" method to be that I would pass it data that would be inserted in the database, and then the method would determine that record's number and return it.
If key is record number, then it is not specific for data. Same data should have same key. Are data dependent on your key?
Let's say record number is key: If I give you data (without record number), how would you find if this record is already in DB? You would probably search every record to compare values with data, but if you do this, then your key is useless, it is not identifying data in 1:1 relation.
John, what if I want to have two identical records in the database? For example, what if two identical hotel rooms do exist (same city, same rate, same date, same hotel name, all fields in the database are the same)? This is a possibility, especially if a hotel does have two identical rooms available for booking.
In this case, I would not mind duplicate entries in the database since in reality, two rooms with the same attributes do exist.
Or is that what you were trying to point out? I still do not understand the purpose of a "key."
It depends on data you have. I'm not familiar with your assignment. If that is the case, that duplicates of data you have are allowed (and desired) then you are probably right.
I always imagine 'key' in this DB like 'primary key' in some relational db. And then of course all around it. Yes of course your table can have index, but I'm not sure if I would choose that as primary key if it were relational db.
I understand what you were thinking; it's the same as my first impression when I read the project specs.
However, there is no primary key in the database. The only thing remotely like it is the record number, but that record number is not persisted in the database file; rather, it is determined by the server/database application.
I believe I read elsewhere on this site that someone else was confused as well, and just decided to implement the exception class, but never throw it. I think that I will go with that path unless I have an epiphany
Yeah, but does being a ninja come with a dental plan? And what about this tiny ad?