|
Replies:
14
-
Last Post:
Jan 29, 2008 5:12 PM
by: shreedhar_ganap...
|
|
|
|
|
|
|
please recommend a small-scale replicated database.
Posted:
Jan 25, 2008 6:42 AM
|
|
|
Hi everyone,
I have a project with two independent glassfish instances. It is not a cluster.
I need a lightweight persistent storage replicated between the two for
some application level authentication data. I would only access them
via JPA.
The data size (few hundred records) and the load (writes hardly ever,
a few reads per minute) are small, so speed or efficinecy are not
issues. Constant overhead and unnecessary complexity are.
(I wouldn't want to fire up a sequoia cluster for this for example, no
matter how much I love it for real databases.)
There already are independent PostgreSQL databases on both sides if
those can be used non-exclusively for this, but I'm hoping there is
some lightweight java database doing just what I need which I haven't
heard of yet. 
Any advice appreciated!
Gabor Szokoli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 25, 2008 6:57 AM
in response to: Gabor Szokoli
|
|
|
I think MYSQL is also good
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 25, 2008 8:23 AM
in response to: Gabor Szokoli
|
|
|
I did something like this using HSQL.
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 25, 2008 9:00 AM
in response to: Gabor Szokoli
|
|
|
Have a look at the H2 Database Engine http://www.h2database.com/. Its small, nice and Java.
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 25, 2008 9:40 AM
in response to: Gabor Szokoli
|
|
|
Stop thinking object-relational, think object only. Db40 (http://www.db4o.com) is an ideal solution in this case. Manage your objects as POJOs with extremely small in-memory overhead.
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 27, 2008 6:04 AM
in response to: Gabor Szokoli
|
|
|
if it is that small amount of data, here is what would i do if there is NO JPA:
1- use an in memory data structure of your own. this is the fastest.
2- use an object database (easiest to query, but no SQL)
3- use H2 or a similar embedded db with a simple jdbc abstraction.
if there is JPA required, that is a shame.. the lightest weight one is toplink i think. Hibernate requires 10+ jars..
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 27, 2008 1:18 PM
in response to: ahmetaa
|
|
|
I'd like to thank everyone for the ideas.
Glassfish with toplink and postgres (with another database in it) are
already present, so I don't consider them as overhead. The project
already uses JPA, so I'd prefer not to have two kinds of persistence
architectures.
The problem is that I need the data replicated between two nodes.
h2 clustering looks interesting, if I can automate the recovery.
ha-jdbc seems to have that aspect covered too, so that's my prime
candidate right now.
I tried to figure out which postgresql multimaster replication
projects are still alive but already stable, but an RDBMS-agnostic
solution is always preferred anyway.
Thanks again everyone!
Gabor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 27, 2008 1:52 PM
in response to: Gabor Szokoli
|
|
|
Hi Gabor
I'm late to the thread.
Gf comes with Shoal libraries and given that your requirements are
pretty lightweight you could consider using Shoal's shared cache
implementation wherein your instances can join a named group and put
shareable data into this shared cache. The data will now be available
in both your instances. Before you call your JPA API for reads you ask
the shared cache for passing in the key. You will have to take care of
removing expired authenticated sessions.
Let me know if this interests you and I can send you more details.
Shreedhar
Sent from my iPhone
On Jan 27, 2008, at 1:18 PM, Gabor Szokoli <szocske@gmail.com> wrote:
> I'd like to thank everyone for the ideas.
>
> Glassfish with toplink and postgres (with another database in it) are
> already present, so I don't consider them as overhead. The project
> already uses JPA, so I'd prefer not to have two kinds of persistence
> architectures.
>
> The problem is that I need the data replicated between two nodes.
>
> h2 clustering looks interesting, if I can automate the recovery.
>
> ha-jdbc seems to have that aspect covered too, so that's my prime
> candidate right now.
>
> I tried to figure out which postgresql multimaster replication
> projects are still alive but already stable, but an RDBMS-agnostic
> solution is always preferred anyway.
>
>
> Thanks again everyone!
>
> Gabor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 28, 2008 12:54 AM
in response to: Shreedhar Ganap...
|
|
|
On 1/27/08, Shreedhar Ganapathy <Shreedhar.Ganapathy@sun.com> wrote:
> Gf comes with Shoal libraries and given that your requirements are
> pretty lightweight you could consider using Shoal's shared cache
> implementation wherein your instances can join a named group and put
> shareable data into this shared cache.
Yes, this is exactly the kind of thing I was hoping to find built in
to one of the many java dbs or JDBC proxies out there
I don't run the glassfish instances in cluster though.
Thanks:
Gabor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 28, 2008 10:47 AM
in response to: Gabor Szokoli
|
|
|
>
> Yes, this is exactly the kind of thing I was hoping
> to find built in
> to one of the many java dbs or JDBC proxies out there
>
For a little while we were toying with the idea of using Shoal inside Derby for building a shared cache Derby cluster. Have not gotten around to do that yet.
Anyone in the community willing to jump in to contribute? This will help many users take advantage of such facilities.
>
> I don't run the glassfish instances in cluster
> though.
Any reason why not? Its pretty straightforward with GlassFish.
If there is a specific reason for not having the instances as part of a cluster, then you could still use Shoal as long as your app makes the api calls to join and participate in a named group.
Please see this blog entry for an introduction and example on how to use Shoal with your app. It does not contain the use of the shared cache. I can send you the details on that a little later.
http://blogs.sun.com/shreedhar/entry/shoal_clustering_101
>
>
> Thanks:
>
> Gabor
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail:
> users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 29, 2008 12:15 AM
in response to: shreedhar_ganap...
|
|
|
On 1/28/08, glassfish@javadesktop.org <glassfish@javadesktop.org> wrote:
> >
> > Yes, this is exactly the kind of thing I was hoping
> > to find built in
> > to one of the many java dbs or JDBC proxies out there
> >
>
> For a little while we were toying with the idea of using Shoal inside Derby for building a shared cache Derby cluster. Have not gotten around to do that yet.
h2 does something similar with JGroups. The data can be persisted to
files, which is something we need, but it can't handle recovery when
the nodes restart. I'd have to figure out which node contains the
latest resvision myself.
> Anyone in the community willing to jump in to contribute? This will help many users take advantage of such facilities.
I can not commit neither personal, nor corporate resources at this
time, but we might get back to it later this year. Derby mailing list?
> > I don't run the glassfish instances in cluster
> > though.
>
> Any reason why not? Its pretty straightforward with GlassFish.
Yes, it's great, but not what we need in this specific project:
We have two identical, but independent nodes doing the same thing,
trying to minimise error propagation. Same data is fed to both, same
results expected as output. Think avionics systems, but not as
critical.
Now the replicated database I'm asking about in this thread is just an
auxillary authorisation db, which we do have to share.
>
> If there is a specific reason for not having the instances as part of a cluster, then you could still use Shoal as long as your app makes the api calls to join and participate in a named group.
Didn't know that, thanks for the link too.
We have been trying to keep things container-agnostic, but that might
change down the road
Gabor Szokoli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 29, 2008 5:12 PM
in response to: Gabor Szokoli
|
|
|
>
> h2 does something similar with JGroups. The data can
> be persisted to
> files, which is something we need, but it can't
> handle recovery when
> the nodes restart. I'd have to figure out which node
> contains the
> latest resvision myself.
Interesting. Shoal provides for a recovery server selection notification whereby as long as the failed server's resources are accessible remotely, another surviving instance can recover the resources of a failed member.
This could come in handy for such a use case.
> We have been trying to keep things
> container-agnostic, but that might
> change down the road
The nice thing is that with Shoal being a 100% Java library, is portable as well since you can use it with any container (or for that matter as part of in any Java application).
Thanks for sharing your project's requirements in a bit more detail. Certainly helps our thinking about possible use cases.
>
>
> Gabor Szokoli
>
> ------------------------------------------------------
> ---------------
> To unsubscribe, e-mail:
> users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail:
> users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 28, 2008 1:34 PM
in response to: Gabor Szokoli
|
|
|
I'm wondering why everyone seems to write off object-oriented databases for this use-case. Regardless of which implementation you go for, surely they are more than capable for this sort of task.
Is it a matter of risk?
Lack of training?
Something else?
|
|
|
|
|
|
|
|
|
Re: please recommend a small-scale replicated database.
Posted:
Jan 29, 2008 12:36 AM
in response to: cowwoc
|
|
|
Are we still talking about Gassfish?
On 1/28/08, glassfish@javadesktop.org <glassfish@javadesktop.org> wrote:
> I'm wondering why everyone seems to write off object-oriented databases for this use-case. Regardless of which implementation you go for, surely they are more than capable for this sort of task.
>
> Is it a matter of risk?
Yes.
I have an issue with replication, which I beleive to be orthogonal to
data representation. I'm happy with the ORM JPA provides, and would
consider replacing it with something new an unnecessary risk.
> Lack of training?
Yes. I'm not even sure we are talking about the same thing
> Something else?
Yes: we are lucky if our end users can hadle SQL for manual
procedures, let alone something, well, not SQL.
(can't have the whole system go unusable just because my silly CRUD
app breaks, and the native RDBMS SQL console is an unbeatably robust
fallback.)
> [Message sent by forum member 'cowwoc' (cowwoc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=256221
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
java.net RSS
