LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices


Reply
  Search this Thread
Old 08-30-2011, 11:11 AM   #61
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 313

Original Poster
Rep: Reputation: Disabled
Multiple JREs


I need to have a service program (windows daemon) run in the background to collect data from my devices. In JAVA I guess I would run two JREs one as a SERVICE and another for a GUI to the user. Is there any way to communicated between the JREs besides using a file for the service JRE routine to write to and for the USER GUI JRE to read from? Thank you. Alvin...
 
Old 08-30-2011, 11:37 AM   #62
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,397
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
I think you're over-thinking the Java architecture. Just think of the application(s) as programs/processes, and use whatever interprocess communications API is appropriate and supported on the target architecture. Shared memory would be one of those, on Windows. On Linux, there are other methods as well: message queues & sockets being the most prominent. Each has its particular virtues and limitations. Control systems tend to be very event-oriented, and sometimes the existence of new data is as important as the data itself. Message queues tend to be appropriate for such scenarios. I don't know specifically what is available on Windows. Using files as an interprocess communications channel is almost certainly a suboptimal choice.

--- rod.

Last edited by theNbomr; 08-30-2011 at 05:37 PM.
 
Old 08-30-2011, 04:44 PM   #63
Proud
Senior Member
 
Registered: Dec 2002
Location: England
Distribution: Used to use Mandrake/Mandriva
Posts: 2,794

Rep: Reputation: 116Reputation: 116
Sockets, MQs, RMI, CORBA, I think all were already mentioned as generic/Java-specific standard technologies to use for IPC. Just forget there's the JRE, it's just a wrapper or part of each running program, there's no single VM all the apps are living in, you don't care about it, it's just the abstract standard that allows each OS to be exposed as exactly the same system so that the compiled-once byte code can run anywhere.
 
Old 08-30-2011, 11:20 PM   #64
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 313

Original Poster
Rep: Reputation: Disabled
Java is a closed system that is why it is portable. Sun stopped supporting javacomm for windows. RXTX has taken over the comm role but that makes java less portable. I am even thinking of using C for the SERVICE running in the background for windows. At least C could deal directly with COMx: ports. Then use a file system to transfer the information to the java gui. The info for the gui operates at human speed so the file system should be fast enough. The problem comes in in getting the information into a database. Java can have its own database which would be good as I can't force the user to install MySQL. One job of the SERVICE routine is to collect data from the boxes and put it in a database so it can be analysed and plotted. The SERVICE also acts as a go between with the gui and the devices to translate the gui human interface to packets the devices can understand. I will mostlikely try to use javacomm and RXTX to talk to the devices just as a learning experience to see if it will work as java would give more portability to the software than C.
 
Old 08-31-2011, 06:38 AM   #65
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,397
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
You can use SQLite, which is simply a library that is linked with your application. You don't need to install any third party database server. Speed is not the issue with using a filesystem for a database.
The application talking to your field bus should be simple and easily written in a way that is portable across OS's. C would be appropriate for that.
Have you looked at existing software packages, such as data acquistion or SCADA packages? You're re-inventing a lot of wheels here.
--- rod.
 
Old 08-31-2011, 04:06 PM   #66
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 313

Original Poster
Rep: Reputation: Disabled
Will SQLite also work with java or do I need an interfacing C program?
 
Old 08-31-2011, 04:22 PM   #67
Proud
Senior Member
 
Registered: Dec 2002
Location: England
Distribution: Used to use Mandrake/Mandriva
Posts: 2,794

Rep: Reputation: 116Reputation: 116
Reading http://stackoverflow.com/questions/4...ava-and-sqlite
I'd note
Quote:
be careful with SQLite in multi-user type installations. SQLite has no row locking for write updates and the DB itself is implemented as a single monolithic file.

Write locking is implemented as file locks across the whole DB.
Which echoes what's on the wikipedia page for it
Quote:
In contrast to other database management systems, SQLite is not a separate process that is accessed from the client application, but an integral part of it.
Also note the suggestion of http://hsqldb.org/

Last edited by Proud; 08-31-2011 at 04:24 PM.
 
1 members found this post helpful.
Old 08-31-2011, 06:48 PM   #68
theNbomr
LQ 5k Club
 
Registered: Aug 2005
Distribution: OpenSuse, Fedora, Redhat, Debian
Posts: 5,397
Blog Entries: 2

Rep: Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908Reputation: 908
That simply means that the work of locking on a file-based database has been looked after, and probably better than one could do on a roll-your-own basis. I doubt that the OP's application is going to be either very busy or sensitive to brief lockouts. Still, good to know the constraints.

--- rod.
 
1 members found this post helpful.
Old 08-31-2011, 06:59 PM   #69
paulsm4
LQ Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
Quote:
Will SQLite also work with java or do I need an interfacing C program?
SQLite will work just fine with Java. You'll use the standard JDBC interface - meaning that the *same* Java code will run - with no source changes or any recompiles - with *any* database.

Here's a tutorial on JDBC (it's easy):

http://en.wikibooks.org/wiki/Java_JD...ple_base_class

There are several JDBC drivers for SQLite to choose from. Here are a couple:

http://www.zentus.com/sqlitejdbc/

http://freshmeat.net/projects/sqlitejdbc/
 
1 members found this post helpful.
Old 09-01-2011, 02:14 AM   #70
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 313

Original Poster
Rep: Reputation: Disabled
WHAT I am leaning to now is writing my own flat file database primatives. I don't need all the bells and whisels. Just a file containing the database fields and types and maybe an ISAM file for the database. It is all internal anyway and could run as a SERVICE detached from the SERVICE accessing the devices and detached from the gui that the single user would be using to update the various variables used in controling the device that he/she is currently accessing.
 
Old 09-01-2011, 04:16 AM   #71
Proud
Senior Member
 
Registered: Dec 2002
Location: England
Distribution: Used to use Mandrake/Mandriva
Posts: 2,794

Rep: Reputation: 116Reputation: 116
Don't reinvent another wheel, just use something like SQLite and move on to the specifics of your device & the problem/solution it's for.

My point about the locking is that I think you'd need one instance of your system to be engineered to the gatekeeper to the DB, aka the DBMS, whereas something more fullblown like my/postgreSQL come with that and a bunch more. With them your remote sensors could insert their data rows directly whenever and the DBMS manages things, the tradeoff being the extra storage and running resources cost of a relatively small instance of them, rather than the possibly slimmer integrated SQLite + hand-rolled wrapper. But I could be wrong with how you want to structure your system's interactions, maybe you always want your sensor devices to talk to your central service and send their data via that anyway. I could be wrong about SQLite and multiple db clients/users. But all I think you'd need to do is read which solution is right and then use it, not rewrite one of them to be the other.
 
1 members found this post helpful.
Old 09-01-2011, 12:20 PM   #72
schmitta
Member
 
Registered: May 2011
Location: Blacksburg VA
Distribution: UBUNTU, LXLE
Posts: 313

Original Poster
Rep: Reputation: Disabled
If I did use SQLite I would most likely need to run it as a SERVICE in ist own right with maybe one file into it and one file out-of-it just like the device SERVICE routine That wouild serialize the access of the database and I would only have to lock the file in-to-it so that the device SERVICE and the GUI routine could only access the input file one at a time. I would include a username of DEVICE or GUI so that the device SERVICE routine and the GUI would know who the output record was for. Not that this database would be in C and not be as portable as java. I could use HYPERSQL which is java based though
 
Old 09-01-2011, 12:47 PM   #73
Proud
Senior Member
 
Registered: Dec 2002
Location: England
Distribution: Used to use Mandrake/Mandriva
Posts: 2,794

Rep: Reputation: 116Reputation: 116
Why would it have to be in C?
Why can't you put MySQL or PostGreSQL or some other DBMS with your installer rather than recreate your own?
 
1 members found this post helpful.
Old 09-01-2011, 12:56 PM   #74
MTK358
LQ 5k Club
 
Registered: Sep 2009
Posts: 6,443
Blog Entries: 3

Rep: Reputation: 721Reputation: 721Reputation: 721Reputation: 721Reputation: 721Reputation: 721Reputation: 721
Quote:
Originally Posted by schmitta View Post
If I did use SQLite I would most likely need to run it as a SERVICE
I thought that SQLite works like a library that you program uses, and does not run as a deamon.
 
1 members found this post helpful.
Old 09-01-2011, 01:03 PM   #75
Proud
Senior Member
 
Registered: Dec 2002
Location: England
Distribution: Used to use Mandrake/Mandriva
Posts: 2,794

Rep: Reputation: 116Reputation: 116
I think we're going in circles now. Yes AFAIK it's an integrated part of your program, which is fine assuming you have one instance trying to use the database. For a system with a central server, many remote nodes reporting to the database, and a GUI reading it, something needs to manage things and I don't think SQLite is strong at this. So one must either work with the limitations (possibly just having to wait and try again for inserts/updates), write your own managing service, or use something with a pre-made DMBS. I could be wrong.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Enterprise LAMP Summit & Big LAMP Camp LXer Syndicated Linux News 0 09-21-2009 01:51 AM
LXer: LAMP vs. LAMP Rematch LXer Syndicated Linux News 0 11-08-2006 03:03 AM
A program for FC4 to communicate with a Windows Hyperterminal Program at other end vhasun Linux - Software 2 05-19-2006 02:54 PM
My C Chat Program is unable to communicate. mcp_achindra Programming 1 03-20-2004 10:04 AM
program to communicate directly with ethernet sabby Programming 4 12-18-2002 11:37 AM

LinuxQuestions.org > Forums > Non-*NIX Forums > Programming

All times are GMT -5. The time now is 04:03 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration