• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

non-persistent EJB

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, im quite new to j2ee, so pls forgive me if i ask simple/stupid questions.

Is it possible to create EJBs without a DB behind them?

SessionBeans are only visible for one Client, so shared Instances must be EJBs or? Currently i just need a in-memory Bean being transactional visible to all clients. I dont need it persistent, so i thought it might be a fine idea, to avoid persisting the bean for speed-issues.

Is there some kind of Bean available for such a purpose?

Would it be possible to replicate such a in-memory bean to a failover clusternode?

Or is it necessary to persist beans being visible to all clients? (Why?)

Another question concerning clusters:
Is the appserver itself responsible for the replication process? Or is it necessary that the db itself supports some kind of master->slave replication?

thx for your help,
Bernhard Neuhauser
 
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Bernhard Neuhauser:
Hi, im quite new to j2ee, so pls forgive me if i ask simple/stupid questions.

Is it possible to create EJBs without a DB behind them?

SessionBeans are only visible for one Client, so shared Instances must be EJBs or? Currently i just need a in-memory Bean being transactional visible to all clients. I dont need it persistent, so i thought it might be a fine idea, to avoid persisting the bean for speed-issues.

Is there some kind of Bean available for such a purpose?

Would it be possible to replicate such a in-memory bean to a failover clusternode?

Or is it necessary to persist beans being visible to all clients? (Why?)

Another question concerning clusters:
Is the appserver itself responsible for the replication process? Or is it necessary that the db itself supports some kind of master->slave replication?

thx for your help,
Bernhard Neuhauser



Yes, you can have a entity bean without a EJB. There are two types of entity beans - Container managed Persistence and bean managed persistence. In the former the persistence is provider by the EJB Continer and the later the developer is responsibe for persistence. If you are connecting to legacy system and your container does not support persistence for that system you could use BMP beans.

Using a single instance of entity for all clients does not work in a clustered environment. You will need to perist data so that other instances in another server of the cluster see the data. Are you using a database?

App server will take care of all replication. Please read your app server document.
 
Bernhard Neuhauser
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
thx for your Feedback


Using a single instance of entity for all clients does not work in a clustered environment. You will need to perist data so that other instances in another server of the cluster see the data. Are you using a database?



Hmm, i hoped that in-memory replication would be able to do this job.
Also im not sure if i ever need a true "cluster".

I just need some kind of mirror being able to act as failover server. I dont need loadbalancing - im only interested into avoiding downtime. (Is this already a cluster?)

So something like
"master" => "read only slave till failover"
would be more then enough.

I thought that modern application servers might have the ability, to cluster beans in-memory within their transaction scope. Yeah i know, that this will lead to the problem, that a normal shutdown will throw avay all instances, but currently - after shutdown - i dont need them any longer (they got a short-time life cycle).

Maybe i just try to archive the wrong goal. The idea was to avoid a locally installed database on our appserver to reduce maintenance efforts. (But maybe it will be already enough to use an embedded db like derby? Seems like some appservers deliver an embedded db to store session states.)

Or is it even worse and both nodes need to be connected to the same db instance?

Seems like there are still huge gaps inside my knowledge ;P

thx again
Bernhard
 
Pradeep bhatt
Ranch Hand
Posts: 8945
Firefox Browser Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

In memory replication is provided for Stateful Session bean but not for entity beans because in entity bean the data is persisted and therefore will be available to other instances of the entity.
I was under the impression that you wanted to use a single instance of entity in a server for all your client. I suggest you read this Weblogic link on clustering

http://e-docs.bea.com/wls/docs81/cluster/
 
Yeah, but does being a ninja come with a dental plan? And what about this tiny ad?
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic