I want to create some kind of grid of javaee applications. To identify each device i would generate an uuid on first start, but what is a good practice to store it?
i am using javaee 7 (wildfly) as platform. Is there probably a "native" javaee way or one specific to wildfly? I don't want to use database (jpa) for a single uuid. If there is a ways that don't need further configuration (set path, datasources, properties) it would be fine.
thanks in advance
your major problem is to store the device id . And you don't want to use any kind of DB?
Cording to me use JSON or XML file for storing so you can use in memory object, which stores the new device id at the run time and while can write into the the a file every time the application is shutdown or the server is shutdown. If this doesn't seems effective as the server or the application can get shutdown due many reason and u need to take care of all those . So its better go with writing into file on the interval of certain time.
Next time when the application is restarted load the JSON or XML in the in memory object. and keep the file appending.
Related
So i have a problem. Currently my application connects with single database and supports multi user. So for different landscapes, we deploy different application all together.
I need a solution that my application remains the same (single WAR deployment) but is able to connect to different DB across different landscapes.
For example a user in UK is using same application but underlying DB is in UK and subsequently another user logs in from Bangladesh and he sees the data of DB schema for Bangladesh and so on.
Currently we are creating JDBC connections in a connection pool created out of java and taking the same through out the application. Also we load static datas in hashmaps during the start up of server. But the same would not be possible with multiple DB since one would overwrite the other static data.
I have been scratching here and there , If some one can point me in the right direction, would be grateful.
You have to understand that your application start up and a user's geography are not connected attributes. You simply need to switch / pick correct DB connection while doing CRUD operations for a user of a particular geography.
So in my opinion, your app's memory requirement is going to be bigger now ( than previous ) but rest of set up would be simple.
At app start up, You need to initialize DB Connection pools for all databases and load static data for all geographies and then use / pick connection & static data as per logged in user's geography.
There might be multiple ways to implement this switching / choosing logic and this very much dependent on what frameworks & libraries you are using.
I have 2 differents applications (Web app and Desktop app) with differents database servers but same structure.
I want to have the same data in all databases, no matter where the user insert/update/delete a record. This is the easiest for me but I don't think is the optimal.
So, for example, if I insert a record in the desktop app, this record must be inserted into the web app server ("cloud") and vice versa.
I'm using Spring+Hibernate+PostgreSQL for the web app and JavaFX+Hibernate+PostgreSQL for the desktop app.
I'm considering 2 options at the moment:
Use sockets to send messages between servers every time a record has been inserted/deleted/updated.
Use Triggers and Foreign Data Wrapper in PostgreSQL. I'm not too familiarize with this, so I don't know if I can make what I want with this option. Can they work together?
There is another option? What do you think is the best?
The simplest and maybe best solution is to have one central read-write database and several physical replication standbys.
The standby servers will be physical copies of the main database, and you can read from them (but not modify data).
in my project I have different applications that all need a database connection (all "apps" are running on the same server) now my question is, what is better:
one "backend" that get requested from the apps through netty or something and has the one and only mongodb connection and cache with redis
or
all apps have mongodb connection and global cache with redis
Thanks in advance
TG
//edit
all applications are for the same project so they will need the same data
I would suggest you to write separate Backends for each Application as tomorrow you might want to have different connection requirements from each application. For eg : One application might decide it doesn't want to use Mongo DB at all . One application might want to use more connections and might be a noisy neighbour for others. Unless you are willing to write a Full Policy based server which can cater to the unique requirements of each application.
I'm working on a project that has two different parts. It's an e-voting system, so there's the part where voters vote, and there's the part where the admin can make changes like adding a new position, candidate, etc. I put these two parts in two different project folders called the client and the server. Each candidate has the URL of their picture, which is also stored on the server machine, which should be displayed to the client depending on which candidate is selected. The problem I'm having is how to read the picture from the server into the client application. Any tips on the best location to store the files such that I can pass just the server name as a parameter to the client and it's able to retrieve the file.
The application uses MySQL, and I'm so far assuming that the database server is the same as the application server.
Also, I was wondering of the possibility of storing the file in the database itself, and if so, how practical that would be in terms of speed.
Thanks.
Single point of information is helpful - so put the picts in the database, if possible. If you do it right, there is not more performance penalty than with other client-server-communication. If the client keeps running you can cache the pictures.
I haven't understood the two folder thing. The server folder must be synchronized to the client? Why? Why don't you store thinks like a new position in the database also?
You can use mySQL database but it's not designed to do that it might be slow, you can use MongoDB with GridFS or use some kind of file repository like Apache Jackrabbit.
In the application Im writting the server will have information abuot the users, using a XML databse. The admin user will be able to write/read information on those files too.
How can I deal with concurrent access to those files?
The only way users/admin can read/write to those files is by requesting to the server(Sockets, TCP connection), so the server will have to handle this.
What can I do? I could synchronize server methods, but I dont want to avoid USER A to access his files while the admin is writing on USER B files.
Use a database instead of files is my first suggestion, they handle locks already.
You should post an example of file structure. It could be done if User A has his data in fileA.xml and user b has his in fileB.xml by locking the given file and synchronizing based on that.
As Jes says use a database.
MySQL Supports XML: http://dev.mysql.com/tech-resources/articles/xml-in-mysql5.1-6.0.html
Most databases support XML, or you could simply use a VARCHAR that is long enough and get and put the data in there. If that is your plan then maybe a NoSQL Solution would work also, it is just a persistent HashMap that supports record locking as well as other features.
It sounds like there is no conflict between users, what you could also do is have an area for the admins to modify the files, which you would copy daily to where the data is read from for the users.