• 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
  • Liutauras Vilda
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Scott Selikoff
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
  • Frits Walraven
Bartenders:
  • Stephan van Hulst
  • Carey Brown

java concurrency - synchronized block

 
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everyone
I have a thread issue in my code that should not be happening - but is. So I'm trying to make some work around. I will try to explain my problems with simple code as I can - because the code that I'm experiencing the issue is big and complicated so in short the code:


So my problem begins when two thread are trying to execute-read-write changes on the same jobObject at the same time that makes mess in my application
What I need is a way that when a thread is entering "if(job.getStatus.equals("redye")){" with e.g. job object with id=1111 no other thread can enter this code for the same jobObject-1111 until the first thread is finished - leaves the if statement
I also have problems synchronizing it because the "execute" method is call with different instance of ExecuteJob
I can use ExecuteJob.class for synchronization but I will lose the point and benefits of multithreading
I'm wondering if there is something like this that can be implemented for my issue:

or maybe
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don't use a static variable to store the thing - that static variable is used by all instances, and so you would have synchronization issues with it. But there is no need for the variable anyway - just use the method-local Job variable:

What I don't know is if the same Job instance is used by all threads, or if getDBJobsFromPath(path) creates new instances each time it is called. If it creates new instances, then we have to see more about the problem, but maybe using database locks would be best.
 
Aleksandar Mitrev
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Steve for your quick reply
So in my case the same record is retrieved from DB-tabale job, but two different instance are been created for example:
Thread-1 gets it from DB and initialize Job job1 = readByIdFromDB("1111")
Thread-2 gets it from DB and initialize Job job2 = readByIdFromDB("1111")
so the expression job1==job2 gives false
but for job1.equals(job2) will return true
From what you are saying and I was able to understand synchronization wont going to work for me in this case. So can you tell me more about that database locks, how can I use it in my problem. I'm using postgres and I'm not rely familiar with this
 
Steve Luke
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Here is the Postgres documentation on locking: http://www.postgresql.org/docs/8.2/static/explicit-locking.html You will need to match the level of locking to whe Object you want to lock, not sure if it is Row or Table. What I would think you would do is provide each Job with a reference to some Database Access Object which knows which Table/Row to lock for that Job.


Then you could use the code like:


All the other DB calls would use the same connection the lock creates, and the unlock would commit (or rollback) the transaction. But to be honest my JDBC knowledge is getting rusty and I have never used PostgreSQL, so use with care.
 
Bras cause cancer. And tiny ads:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic