• 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
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

How to circumvent client-side locking?

 
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I designed my FlightModel class to serve as an adapter for an instance of the Data class. FlightModel provides the same functionality regardless of whether the "data" instance held within is created on the local machine (DataExtension) or returned by an RMI request (RemoteData).
My dilemma is that I cannot find a solution that will enable my code to circumvent the locking process that occurs when reading/writing/modifying the database when the Data instance resides on the local machine. The reason for this being that the adapter methods of the FlightModel are atomic regardless of the location of the Data instance.
Now, I could add conditional logic to check an "isRemote" flag that's tripped when an instance of RemoteData is returned. When this flag is false, the code would delegate to non-locking code that performs the read/write/modify actions. To me, this seems an ugly way getting around the locking issue.
Has anyone experienced this and/or successfully designed around the issue?
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Christian,
Why do you want to circumvent the locking in local mode?
I can understand the opposite argument: if you currently dont have any locking in local mode, you don't really need it, so you may not want to code for it.
But if you already have locking working in local mode, then why not leave it alone? What is the downside? I could even argue that from a mainenance point of view, it is easier for someone to maintain code if the locking is always happening, rather than the maintainer needing to determine what mode they are in.
Regards, Andrew
 
Christian Garcia
Ranch Hand
Posts: 77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Andrew,
I agree with your comments 100%. I went over my code last night for quite a few hours re-analyzing the design. I came to the conclusion that having locking/unlocking occur on a local database shouldn't impact performance. Your point:

I could even argue that from a mainenance point of view, it is easier for someone to maintain code if the locking is always happening, rather than the maintainer needing to determine what mode they are in


falls in line with the existing implementation of my code.
Thank you for your input.
 
World domination requires a hollowed out volcano with good submarine access. Tiny ads are optional.
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic