First of all I am a beginner at JSF, I still don't get some JSF concepts properly like FacesContext. I have searched the solution for the below problem, but I couldn't find anything useful for me.
I have a <rich:extendedDataTable> with some data from a database table. And have a managedBean providing the data from a pojo as a java.util.List<myPOJO> object to <rich:extendedDataTable>.
I can get the selected rowkey on this managedBean. But the database has some other users who can delete records. At this point if one of them deletes any record at the database table, <rich:extendedDataTable> will not have any clue about the deleted row and it will still refer the old number of rows. In this case the rowkey will refer to the (selected row + 1)th row after deletion.
I would like to refer to old data and get primary key from it, then to look if the data with this primary id still exists.
I cannot use primary key on the table for security and design purposes. I don't know if there is any way to keep primary key data on the page securely, or to get it correctly at the managed bean, even after data deletion by other users.
I cannot use <rich:dataTable> etc, since I want sorting enabled at data table.
I think there must be a solution at managedBean side, hence I choose JSF thread of the forum
I really appreciate your help, I got stucked with this problem
This is a fairly advanced problem, and the solutions require a lot of careful consideration, plus a very strong background in multi-user, multi-threading, and transaction management. Not something that you farm out to "Programmers "R" Us" for the lowest bidder, in other words.
In almost all cases in JSF, a tabular display of persistent data is going to be done courtesy of a DataTable or subclass of the DataTable infrastructure and it's typically going to be done in session scope. Request scope is too transitory and application scope doesn't lend itself well to multiple people viewing different sections of the data concurrently. Thus, each user has a session bean that contains the datatable's corresponding DataModel.
One reason why you need a datamodel instead of just presenting the back-end data directly to the UI is, in fact, the per-user nature of the display. The datamodel allows a common data source to be viewed filtered, sorted, even enhanced as needed and it supports the cursor required to be able to select a row in the model and act upon it.
If you do a "show source" on a DataTable HTML page, you'll notice that the only actual data that displays is what you choose to present. So if you don't present a primary key, one won't be sent to the user's browser. The actual referencing of the data is done via an index (notice the "id" attributes for each displayed row).
Once the user has initiated action on a row in a DataTable, the backend action processor can tell which row was selected by referencing the DataModel's "current row" attribute. Since the DataModel can contain the primary key safely, that's enough to resolve back to a specific database record. The DataModel never leaves the server, so it's a secure place to keep such information. If anyone breaks in at that level, you're already massively compromised anyway.
The real fun begins when you have multiple users working on the exact same data.
JSF does not provide a "live" display. So if I delete 37 records and they're being displayed in your browser, you won't know about it until the next time (if any) that you make a browser request. If I change 12 records and you change them too, there's a conflict. How you resolve the conflict depends on what you want to do. In some systems, data is "locked" for editing, and any other user has only restricted access (if any) to the locked record. Typically they can read the old version, but until you commit the changes and unlock the record, they can't see any of the changes you made. Sometimes access is totally denied. Occasionally, there's a conflict resolution mechanism that needs to be implemented. Consider, for example, the case where a counted in a record that gets updated every time someone views it.
This is an old problem that dates back to long before the Internet and whole books have been written on that topic.
Sometimes the only way things ever got fixed is because people became uncomfortable.
By the way I figured out what's wrong with my code. It' s about loading records in accessor method. Everytime I need db records it loads updated version, because there is no control on what control is requesting it. I put it in a if statement, and it works.
What a stupid mistake!!! What a stupid mistake!!! What a stupid mistake!!!
Can't .... do .... plaid .... So I did this tiny ad instead:
Free, earth friendly heat - from the CodeRanch trailboss