• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Record Locking in Data.java

 
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,

I am working on the B&S 2.3.2 project and I am starting to get confused about where I need to have record locking (I'm probably just looking at it for too long!!)

I have the Sun provided DBMain.java interface which is implemented in Data.java. I have decided implement a "thin client" i.e. the GUI will only be able to call Book() and Search() methods. These business methods are in a class called DBServerImpl.java.

In pseudo code one of the business methods would be similar to:


So far everything is fine!

My question is do we need to provide a similar level of record locking in the Data.java class? For example do we need to be concerned about other programs who might not use the business methods in DBServerImpl (i.e. Sun Test Harness, B&S legacy application etc) and would call methods randomly in Data.java? So would we need the following in Data.java?



Or is it enough presume that we only need to be worried about record locking in the DBServerImpl.java class above and Data.java is simply a wrapper to the Database, as follows:



I hope my question makes sense!

Thanks in advance,
Ian
 
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would be curious to know what is a right answer, too.

I didn't deal with locking in the DBMain and like your first sample, I did it in the business layer.
 
Ranch Hand
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Ian.
Mine is too a 3 tier solution. But it is cookie based, so this situation is completely different.

For example do we need to be concerned about other programs who might not use the business methods in DBServerImpl


Absolutely yes!
Think in your DBServerImpl like it was other Data class client.
If Data behaves correctly, both, business and data clients, can coexist without problems.
In your case i would not call lock within update method, since it is in the interface too.


Cheers,
Oricio
 
Ian McGarry
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Oricio,

Thanks for the advice!

Just so I understand what you are saying, am I correct in saying that the update(), create() and delete() methods in Data.java should only check if the record is locked but not actually try to lock it as I suggested?

Cheers,
Ian
 
Ian McGarry
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Oricio,

Thanks for the advice!

Just so I understand what you are saying, am I correct in saying that the update(), create() and delete() methods in Data.java should only check if the record is locked but not actually try to lock it as I suggested?

Cheers,
Ian
 
Oricio Ocle
Ranch Hand
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Ian,
yes, that is exactly what i tried to mean.

Regards
 
Oricio Ocle
Ranch Hand
Posts: 284
Netbeans IDE Firefox Browser Debian
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello again Ian,
In order to identify a client, in a non cookie-based RMI environment it could be good you consider a "Connection factory" solution.

Regards, Ori
 
Ian McGarry
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Orico,

Thanks for the speedy reply! I am already using an RMI Factory pattern which allows me identify the owners of the locks. So I think I should be fine!

Thanks for the help,
Ian
 
Ian McGarry
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Orico,

Thanks for the speedy reply! I am already using an RMI Factory pattern which allows me identify the owners of the locks. So I think I should be fine!

Thanks for the help,
Ian
 
Ed Tse
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ian, can you show me samples of your RMI factory pattern on how you would identify a client?
 
Ian McGarry
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Ed,

There are loads of discussions on the board about using RMI Factories. Here is only one:
RMI Factory Post

You could also look at:
Applying the Factory Pattern to RMI

Andrew also covers it in his book.

But the basic idea is that you create a new instance of the Data class for each connected client. The Data class in then passed into your lock method and used to identify the owner of the lock.

Cheers,
Ian

PS: not sure why my posts are appearing twice! Maybe something dodgy going on with the network here in work...
 
Ed Tse
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I tried to look through the threads but I still am not clear. The method depended on the Connection Factory to have a data object created for each remote client. I thought the requirement to implement that in the data class so that whoever that is using DBMain Interface not using all the business layer or what so ever can be able to identify the client that called lock and unlock. I am so confused.
 
Montana has cold dark nights. Perfect for the heat from incandescent light. Tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic