• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

URLyBirds Adding and Deleting

 
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey all, i have a rather odd question. In the Data classes interface (supplied by sun) there are 2 methods 1 for adding and the other for deleting records in the database file.

In the assignment document however there is no mentioning that the records must be added or deleted.

Im not sure what to do as i know that some of the assignment is to follow the specification and i dont want to stray away and be penalised.

So basically what my question, is should i add the functionality in the GUI to add and delete records? So the user can add and delete records.
 
Ranch Hand
Posts: 225
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I remember I've read here that some people did'nt implement the create and delete methods of the Data class (throwing an UnsupportedoperationException).

I think it's a little bit "extreme" even if doesn't violate the must requirements.
But adding the create/delete functionalities to the Data class doesn't imply that you should add a way for adding and deleting records in the GUI. It does
simply let the database ready to support those methods.

It's just my point of view...
 
Patrick McDonogh
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thants actually what i have done, but am worried that implementing the methods may give an area to loose marks, however its not over complicating the code so i ct see why it would.

Thanks for the reply
 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Patrick,

You belike to create some records for test your application, so you�d have to write the create method.
For the delete method, it would be usefull not for the GUI (customers), but for someone who administrate the business. Althought it�s not a real applications, you should ( not nust ) see it like a real one.

M�rcio
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The possibility of deleting and adding records add some concurrency issues to your application that would not be there if they did not need to be supported.

I think it would be legal not to implement the delete and add methods, as long as the other methods would be compatible with them. For example, the lock method should check if the record it had been waiting for has been deleted whilst it was waiting. (Hint: failing to do this is a strong candidate of the source for the infamous 44/80 locking score.)

I took the safe road however and implemented both completely. As mentioned above, the methods are very convenient for your testing.

Frans.
 
Ranch Hand
Posts: 103
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frans,

For example, the lock method should check if the record it had been waiting for has been deleted whilst it was waiting. (Hint: failing to do this is a strong candidate of the source for the infamous 44/80 locking score.)



Is that so?? - my implementation is as follows:

1.Wait for a lock on a record.
2.If the record is free, acquire the lock.
3.check for record validilty and if it still exists, do the update.
4.Release the lock?

Can you explain how would the case of not checking record validity (whether it is deleted or not) before locking, will be wrong in a real time situation?

Regards,

Muthaiah.
 
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Mmm...at last an idea on how 80/80 becomes 44/80.

So looking at my code again below...



It seems to me that the record I was waiting to lock could have been deleted while I waited on it.

So if i put a isValidRecord(..) check at the start of the while loop it should solve that and put me well on the way to avoiding the dreaded 44

Any sees any flaws in my reasoning ?
 
Ranch Hand
Posts: 329
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator



public void delete(int recNo, long lockCookie) throws RecordNotFoundException, SecurityException
{

}

public int create(String[] data) throws DuplicateKeyException
{

return newly_created_record;
}



So basically you leave above method empty in Data.java (you implement from DB interface (in URLBird)

Thanks
 
reply
    Bookmark Topic Watch Topic
  • New Topic