I'm using a primefaces datatable to show some data of my application. My problem is, i have 20 rows on this datatable, but each row has data from 3 different databases, so my datatable is composed by 60 different databases. Once the datatable is only rendered after all the rows are completed it takes a little long to show the component... I was wondering if it's possible to make the component be rendered after each row be completed, maybe using threads or any other solution...
James Boswell wrote:Erm you don't mean 60 databases, I think you mean 3. Regardless of how many rows your datatable contains, the actual data comes from 3 databases.
My first question is why is the data spread across 3 databases?
Nops... I really have 60 databases... For the row 2 (BHT) i have DB 4, DB 5 and DB 6.... Each row represents one state in my country and each state has 3 databases.. I know that is an unusual situation, but i really have 60 databases, and more than that i have the follow situation... On the image, where i have DB1, the information are in one state, DB2 in another state and on DB3 in another.. I mean, the databases are physically in different states...
I think the reason of so many databases is because this databases with less than one month reach 100GB
We're having a hard time believing you mean 60 databases, because that would be unbelievably clumsy. It would require 60 different JDBC URLs to connect to them all and the overhead of opening and maintaining Connections to 60 databases would be horrendous.
What we suspect is that what you're calling a "database" is actually something more like a database table. Or maybe a database schema, although that's pretty bad too.
DataTables (whether PrimeFaces or not) work against table models (DataModel objects). So you need an effective way to construct the row elements of the DataModel and to refresh the display as the DataModel adds/changes rows (AJAX can do this).
You cannot do long-running processes using threads in J2EE. It is forbidden by the core J2EE spec and in practical terms, it may cause the server to crash at unpredictable times. You can spawn threads from a Servlet ContextListener and have the JSF beans talk to those threads (using synchronized interfaces). We've discussed that technique more than once in this forum, as well as others.
Just to clarify the scenario that i have, i attached a new image showing the databases.... For each databases (each row, each site) i have two schemas where i need to get some information. Each site is in one different state. And i have another database, where i have one more schema for each site... it is really a nightmare connect and keep the connection on all this bases...
Tim Holloway wrote:We're having a hard time believing you mean 60 databases, because that would be unbelievably clumsy. It would require 60 different JDBC URLs to connect to them all and the overhead of opening and maintaining Connections to 60 databases would be horrendous.
What we suspect is that what you're calling a "database" is actually something more like a database table. Or maybe a database schema, although that's pretty bad too.
DataTables (whether PrimeFaces or not) work against table models (DataModel objects). So you need an effective way to construct the row elements of the DataModel and to refresh the display as the DataModel adds/changes rows (AJAX can do this).
You cannot do long-running processes using threads in J2EE. It is forbidden by the core J2EE spec and in practical terms, it may cause the server to crash at unpredictable times. You can spawn threads from a Servlet ContextListener and have the JSF beans talk to those threads (using synchronized interfaces). We've discussed that technique more than once in this forum, as well as others.
Have you considered partitioning? Is that an option in SQL Server? I cannot believe it isn't.
I had to do something like that for a MySQL database last year. In my case the database was "only" 40GB in unloaded sparse CSV form, but the performance really dragged until I partitioned it.
With a partitioned database you can use a single database and schema and a single JDBC connection. Check with your DBA.
This might be difficult, as each database are in different states..so, to have all the information i need in one database/schema, it would be necessary reply all the information for this "new" database, which might cause a new problem because of the internet links. Some of them are not good enough... I'm not sure if was this what you suggest, but was what i got. Anyway, i'll talk to him and see what he thinks about it... As i am leaving the company i won't be able to keep working on this problem, but i am really grateful for all that help you guys provided me.
Tim Holloway wrote:Have you considered partitioning? Is that an option in SQL Server? I cannot believe it isn't.
I had to do something like that for a MySQL database last year. In my case the database was "only" 40GB in unloaded sparse CSV form, but the performance really dragged until I partitioned it.
With a partitioned database you can use a single database and schema and a single JDBC connection. Check with your DBA.
If your databases are splattered all over the place, the performance for what you initially proposed would be even worse than we imagined. Much, much worse.
If at all possible, I would have a mechanism installed that could scoop up all that data offline and clone it to a central (partitioned) database. There are a number of tools that can help do stuff like that.
All, in all, I'd say that the webapp and JSF components are the least of your worries. This is the sort of problem I get my kicks out of working on - where the challenge is to make many unfriendly entities play nice together and do so reliably and with good performance.
Post by:autobot
It's a pleasure to see superheros taking such an interest in science. And this tiny ad:
a bit of art, as a gift, the permaculture playing cards