Here's my setup:
I have a mySQL database with some data.
I have a makeshift server built where it downloads this data and turns it into an ObservableList and
the client can make its own copy of this ObservableList, call it localList.
If I want to make a new entry, the requirements dictate that it must be done by sending the new entry to the SQL database,
the server downloads it, the client pulls this update,THEN the client sees the update. (This is done since multiple clients will be accessing this database).
Here's my problem:
Currently, the way I do it is when I make a new entry, the server clears its observableList, fills it again, and the client clears its localList and fills it again.
I do not have to worry about the server code (it will be replaced with a more sophisticated server), but I am wondering
if my localList (from ObservableList) comes with some method that can compare to another list and make changes accordingly.
Instead of doing
ObservableList<myType> locallist = FXCollections.observableArrayList();
....
localList.clear();
for (myType element : serverList) {
localList.add(element);
}
Each time I make a new entry, is there a more efficient way? Some type of update method possibly?
Basically the question boils down to:
Is there a way of setting an observableList<myType> equal to another without fully clearing the list and then adding the elements one by one.
Does
Bindings.bindContent(localList, serverList);
do what you need? (Javadocs). It would work if you keep the same list instance in serverList, and don't reassign the reference.
Related
I have an SQLite database which I have to be constantly retrieving data from. Changes may be done to the data between each retrieval.
My goal is to maximize the app performance, so what is the fastest way to do this retrieving?
I can imagine 2:
constantly opening and closing new cursors
query all data at the beginning and store it in an ArrayList. When changing the data, change both SQLite DB and the ArrayList using indexOf.
---- EDITED ----
I need the data to create markers in a google's map.
I have considered using CursorLoader but as I don't need to interact whith other apps I don't want to use Content Providers.
Would creating a custom loader be a good idea?
In short, while it's not always that simple, the fastest way to do things is all at once.
Constantly making calls to and from a database can really make your apps performance bottleneck, especially if it's to a server and not just your devices SQLite database.
Depending on what you're doing with the data, you may be able to look into something like a CursorAdapter which handles the display of rows from the database, and each time you insert/update a row, the CursorAdapter will update the ListView accordingly. It also handles the opening/closing/moving to next of the Cursor, making it very readable and easy for developers to follow.
Again, however, try to do things in as few calls as possible. If you stick to using an ArrayList:
Make one call in the beginning for all items.
Loop through that cursor and add items to an array list.
Use the array list as a cache. Sure, you could update the DB each time you update the list (which might be safest, IMO), or you can just loop through the list and insert/update/delete when the app closes. If you take that approach, make sure you do so in a method like onPause(), as it is one of the earliest methods in which an Activity can be killed.
Perfect use case for a CursorLoader. Given a query, it'll keep your list adapter up to date with the latest data, assuming you notify when changes happen in the DB. It also conveniently handles activity lifecycle events for your (ie. it'll close the cursor when the activity finishes, stop updating when it pauses, etc.).
The fastest way is obviously to not use a database at all. However, that is clearly not a solution unless you find some way of exposing your array to access from elsewhere.
Using a database is a convenient way of centralising the data so many users can access the data and have the data up-to-date at all times. Unfortunately this is the slowest option.
Choosing your middle-ground between speed and availability is a difficult task. You have to find a balance between stale data and throughput.
If, for example, you would be comfortable with a picture of the data that was valid just 5 seconds ago then you could probably cache the data locally in your array and arrange for some mechanism to keep it up-to-date running behind the scenes.
If a 5 minute lag was acceptable you could probably arrange for a regular push to database.
Also, any mechanism you use must also handle parallel changes to the data - perhaps two users change the same datum at the same time.
You just need to decide on where to strike your balance.
I have an application which gets data from a database (Mongo) when a user connects, and saves it when a user disconnects and at fixed intervals to reduce the likelihood of data loss if a server goes down. I am using data access objects to save users to the database which updates every field regardless of if it has been changed. This can lead to problems such as when a user joins multiple servers and makes changes on one of them but the changes are overwritten when the user disconnects from another.
Are there any established ways of persisting only modified fields or any frameworks that do this? I would rather not use a boolean for every field as I have many fields inside the User object and adding a dirty flag to each of them would increase the class size dramatically.
The steps your application takes:
User gets data from MongoDB
This data get's partially modified
The modifications should get saved
This means: The part of your application that modifies the data should take care of that.
The Spring team introduces some Diff tool, a few months ago: https://spring.io/blog/2014/10/22/introducing-spring-sync
Using that, you'll get a Patch object, which only contains the changes.
Patch patch = Diff.diff(original, modified);
Here's an approach that might work:
Object data = mongoClient.getData();
Object modifiedData = modify(data);
Patch patch = Diff.diff(data, modifiedData);
The patch now contains everything that has changed. Now you must somehow use the internals of the Patch object and map that to MongoDB's $set commands.
I'm hoping for some advice or suggestions on how best to handle multi threaded access to a value store.
My local value storage is designed to hold onto objects which are currently in use. If the object is not in use then it is removed from the store.
A value is pumped into my store via thread1, its entry into the store is announced to listeners, and the value is stored. Values coming in on thread1 will either be totally new values or updates for existing values.
A timer is used to periodically remove any value from the store which is not currently in use and so all that remains of this value is its ID held locally by an intermediary.
Now, an active element on thread2 may wake up and try to access a set of values by passing a set of value IDs which it knows about. Some values will be stored already (great) and some may not (sadface). Those values which are not already stored will be retrieved from an external source.
My main issue is that items which have not already been stored and are currently being queried for may arrive in on thread1 before the query is complete.
I'd like to try and avoid locking access to the store whilst a query is being made as it may take some time.
It seems that you are looking for some sort of cache. Did you try to investigate existing cache implementation, maybe some of them will do?
For example Guava cache implementations seems to cover a lot of your requirements - http://code.google.com/p/guava-libraries/wiki/CachesExplained.
I have a page where a user can edit a lot of information, right now about 100 lines worth of DDLs and a text area, I want to update a data object after each change so that I only have to save to the database the changed rows instead of updating every row.
i.e. when the DDL value changes or when the text area data has changed (this is done in a pop up so that it will only be changed when 'Ok' is clicked) it will be stored into an array holding each updated row as an object. When the user hits save, it will only save the rows that were changed.
Right now im using AJAX so that its making a HTTPRequest, getting the array from the session and adding a new entry with the new value. Unfortunately I believe the page is stepping on itself at times and not keeping the data correct. I'm not sure why, but was wondering what would be the best way of implementing this, and if this is a good way of doing this.
Would a Java bean or anything else be better to represent the data object?
Would not accessing and storing in the session be faster and prevent this?
Java bean is very good for this purpose (as compared to java Map).
As I understand you want to call UPDATE only for items that has change, the best would be to implement equals() for that java bean class.
You have to store old values in session or anywhere else on server, to be able to determine what have change.
Anyway, you'll have to loop and do compare for each object:
if (!prevValue.equals(currValue)) {
DAO.update(currValue);
}
Context
I am storing a java.util.List inside ehcache.
Key(String) --> List<UserDetail>
The ordered List contains a Top 10 ranking of my most active users.
Problem
Concurrent 3rd party clients might be requesting for this list.
I have a requirement to be as current as possible with regards to the ranking. Thus if the ranking is changed due the activities of users, the ordered List in the cache must not be left stale for very long. Once I've recalculated a new List, I want to replace the one in cache immediately.
Consider a busy scenario whereby multiple concurrent clients are requesting for the ranking; how can I replace the cache item in an fashion such that: Clients can continue to pull a possibly stale snapshot. They should never get a null value.
There will only be 1 server thread that writes to the cache.
I don't see what the problem is. Once you've replaced a cache item, clients will pull that new cache item. Up until that point they will pull the old cache item.
There should never be a time when they return a null cache item, unless you actually remove the item from the cache and then replace it.
If EHCache worked like that I would consider it pretty fundamentally broken, given that it's meant to be thread-safe!
You can simply store the new list in the cache. The next call to get will return it.
All you must make sure is that no one edits the list that is returned from the cache. For example in the server thread, you must copy the list:
List workingCopy = new ArrayList ((List)cache.get(key));
... modify list ...
cache.put (key, workingCopy);