I've been working on a transactional services which is used as a part of core banking project. In many services, before inserting any records in my database, I should run several validation on the records. It is also true for editing the records which are already exist in the database.
But sometimes in order to update a record in an specified table, we should change records in other tables which are related to the specified table. Consequently, we need a user confirmation to change records on other tables. But the problem is I don't know how could I get a user confirmation in client while I run a transaction in the server. Is it possible to tackle this problem using sending message between client and server through rabbitMq?
I will be appreciate if any one explain any solution using clear sample.
When I would need to implement this, I would do it in an other way (I do not know if this works for your scenario).
I would first let the user input his data,
then I would do a try run and check which additional confirmations are needed I would also save (in the user session) all relevant constraints that are determined while the try run
then I would ask the user for the additional confirmations determined while the try run
then I would do the real-run, and use the saved constraint checks to be save that nothing relevant has been changed meanwhile.
(If there is a relevant change in the data between try- and real-rung detected, I would apologise and start the process with step 2 again)
but this only works if you do not have so many "meanwhile changes"
Related
I'm currently trying to write a simple journal-like program in Java that allows me to add "entries" and be able to browse all the "entries" I have added since the very beginning. The problem is, if I run the program, add two entries, exit the program, and then run the program again, I want to be able to have access to the two entries I previously added. I guess my questions is then, how am I able to "save" (if that's the right word) the entries that I add so that they won't be wiped out every time the program terminates?
I did some looking around, and it appears there's a tool I can use called the Java Cache System, but I'm not entirely sure if that's what I need for my situation. I'd appreciate if somebody could point me in the right direction.
When you run the program and create the entries your storing them in primary storage aka RAM. As you have discovered these entries will not persist across different executions of your program.
You need to store the entries in secondary storage aka the hard drive. This can be done by writing the entries to a file saved on disk and then reading those entries upon startup of the program. Java provides several mechanisms to read and write files to the file system on a machine.
Some applications use a database to store information in a relational manner so that it is available via a SQL request, however I would recommend using a simple file to store your entries.
The simplest way would be to store this data somehow in a file, and then read it from the file when the application starts, a few simple examples on how to write/read from file:
http://www2.cs.uic.edu/~sloan/CLASSES/java/MyFileReader.java
http://www2.cs.uic.edu/~sloan/CLASSES/java/MyFileReader.txt
http://www2.cs.uic.edu/~sloan/CLASSES/java/MyFileWriter.java
http://www2.cs.uic.edu/~sloan/CLASSES/java/MyFileWriter.txt
Now, you store your objects in memory instead of this you can try to serialize them to some format like xml. And then in next run load them from xml. Or you can try to use dataBase for storing objects.
I faced same problem in past but little bit different.I clearly understood your problem , My solution is whatever the journal you are entering and getting saved should be saved in a particular location in your Location such as "C:\Your_Directory\Journal_folder\"
so it will be easier when you initially enter the journal it stores in above location ,again if u exit and reopen the application just try to retrieve the data from the above Mentioned target Location.
therefore every time when ever you enter the application it retrieves the data from that location if not it displays empty
Is there a small framework for Spring 3 & JSP that allows server side form validation for forms that contains normal fields and file upload, which is able to "rejecting" the request without loosing the uploaded file?
In more Detail:
I have a HTML Form that contains normal input fields and a file upload field. The validation of this form is done on server side (it is to complex to do it on client side). There is no problem if the form data is correct.
But the user sends a invalid form then I need to display the form again, the user corrects the input and send the form again. That works fine except the fact that the user needs to enter (and upload) the file again. -- The solution in general is simple: I need to store the file on server side and then use this already uploaded file if the user sends the corrected data again. -- But even if it is not so complicated it is a lot of work, and I do not want to reinvent the wheel.
So my question is, is there any small framework that implement this feature, which I can add to my application?
(At the moment I use: Spring 3.0, JSP, Dojo)
All you really need to do is save the file and associate it with the session, and not to rely on automatic or injected validations which would reject the request without allowing you to save the file first - programmatic validation. Save the file with some kind of association to the session (or the user, if using Spring Security, for example) so it can be used in future requests.
But: that desired solution requires you to establish some offline cleanup of files. I have a similar situation where a process creates a (permanent) "temp" table. When the table is created, I kick off a table watcher process annotated with #Async that loops and sleeps the thread for an hour, checking to see if the table still exists (its deleted by the end of the online process). If the table is still present after an hour, the async thread deletes it and exits. In your case, you need to establish 1) what to check for to see if the user has completed the process, and 2) how long to check for it.
I'm working on creating a checkbook app for android using a database to record transactions. The design I'd envisioned was/is to allow the user the ability to create different "accounts" (savings account, checking account, etc) under whatever name they choose and use that as the database table name. However, using preparedStatements doesn't work when I try to create a table. So I'm wondering if I'm going to need to sanitize the input manually or if I'm missing something. This is my first Java/android database program and I've got no formal education in databases so its possible I completely missed something. **edited to reflect more accurately what I meant by account. As this will be on an android device I have no interest in multiuser setup.
Probably, you don't need a table for each user. You should revise your database structure.
I am working for a company developing web based software J2EE.
On our webapp its possible to upload a csv file. Ive got some kind of reader class which reads each line and processes it. (It checks if the values in each csv line are valid and inserts them into the database). Along with this the reader counts the lines read to show this number at the end of the process.
Users can upload a file and click on the 'process' button, after this the process starts.
But these processes can have a very long duration since the csv files can be very big. When the users closes the webbrowser the process still continues on the server.
I want users to let them follow the progress. Even when they close the browser and log in again. So I guess there should be some kind of ID attached to each process, to know which user's process it is and what the status of the progress is?
Is there some kind of mechanism in Java with which I can accomplish this?
The simplest way to track the progress is to get the process to write its update to a database table - say 'jobs'. When a user uploads a new csv file and hits 'process', you can first make an entry into this table. The process periodically writes to the table its progress. When the user logs in to his account he can see all the jobs he had started and their progress. This is not the cleanest approach but it will get the work done. A lot of things depend on your specific framework. Perhaps you could make an entry into this table with the process id and there wont be a need for you to update the progress in the table. The frontend could then use a RPC to your process to query its progress.
If you store the csv as raw in a table in the database the entry should have a unique UPLOAD_ID. There should be another column in that table to reference the associated CLIENT as a foreign key. In short you need to associate the uploaded entry with the client or username of that client that performed the upload.
I have been asked to implement a file upload program. The program is a Java Web Start application responsible for uploading the contents of a CD to a web application. There are two requirements here:
The uploader should operate in the background with minimal interaction (No rich GUI).
Users may not want to watch the file being uploaded. The user should be able to log out from the system while the uploader is still running. The uploader must continue even if the user logs out.
My gut feel is that #2 is insecure at best and impossible at worst. Basically, to implement such a use case you would need to create a new session id for the uploader; independent of the original session, and without the user's password.
Has anyone had a similar use case? If so, what approach did you take?
I'm not sure why this is complicated even if a user logs out.
Session is started at login, session id assigned.
User begins uploading file with session id information in filename.
e.g. session_id_user_name.DAT
User Logs out
File is complete, background process on host identifies information based on session ID, moves file to location.
User Logs back in later
File is recognized and tied to account.
Security is not an issue since the file stream is still in progress since it was started. Session information could be serialized and deserialized once user has logged back in. In any case the file stream could run completely unattended.
Perhaps i've oversimplified this but it seems straightforward.
From a users POV I can't see #2 ever being relevant. A user thinks if they "log out" then any current operations would be canceled, they would then very likely turn their computer off - in which case there is no way your transfer will keep going. Just let them minimize the interface to a small icon on the bottom right (man having a brain fart can't think of what they are called) of the taskbar in Windows.