I am using Jboss server. Whenever trying to restart server my application is getting logged out. I wont allow user to logout until Log off the applicaion. How to manage this thing. Like gmail i need to do.
You can do it by HA Web Sessions via Database Persistence.
The basic use case we hear for this is environments where sessions need to be available to AS instances located across a WAN. JBoss Cache/JGroups clusters can span a WAN but often users find it impractical to configure their cluster(s) in that way. However, their IT infrastructure already supports making RDBMS data accessible across the WAN. So, persisting sessions to the DB makes them available across the WAN.
For more details visit here
Related
I have a legacy application that runs on Spring 1.0 with Acegi security on JBoss 4. Our plan is to migrate one subset of the application to Tomacat 7 and Spring 4. The user will login to the legacy application but if they want to navigate to the subset that is being migrated they would be redirected to the new app.
My question is how would I maintain session information between the two so that the user can seamlessly navigate between the two apps and maintain SSO. There would be no other information exchanged between the two servers. One constraint we have is that we have to make minimal changes to the existing legacy app.
Any help would be much appreciated.
You can't seemlessly maintain session information as far as I can tell.
You might be able to get insanely lucky by configuring JBoss and Tomcat to be clustered using Tomcat's clustering (and assuming that the Tomcat version shipped with JBoss is compatible with the standalone Tomcat you are running), and then enabling SSO on both JBoss and Tomcat, but then you have to be very careful not to place anything in your JBoss session that is not going to be loadable by the standalone Tomcat instance.
You are probably better-off implementing some other solution like using SAML that will likely be less fragile.
You said you didn't want to make too many changes, but if you are willing to get your hands dirty, you could use a shared URL-space between the web applications, use different session id cookies, and then cross-check incoming requests for unauthenticated users by calling-over to the "other" server to fetch their authentication information (which you'll have to make available in the session in some way). I'd advise against storing passwords in the user's session.. instead allow one application to obtain the username of the user in the other application using the session cookie from the first. Trust that the username is accurate and that the user has been correctly authenticated already in the first application, then perform an auto-login into the second.
Whatever you do, it's going to get messy, since your requirements are fairly messy.
I have developed a Java database application that has been deployed to users via a web server. Now, all is good but it has been requested that some of our external clients would also like access to the software. Is there any way that I can make the application work for these clients? The application has been put on another web sever that is accessible for external users and also has visibility to our SQL server but the application is not working, it will load in the browser but users cannot login to the system which works by database authentication. Am I missing something simple here or is this something that can't be done. I would imagine the latter since I think the web start application downloads to users machines which would explain why you can only login when a VPN connection is active.
Any help on this matter would be greatly appreciated.
Most definitely your firewall blocks the connections to your database when they are initiated from the outside. This is a good thing because you generally don't want to expose a database to the Internet.
One hacky way to do it would be to implement some kind of JDBC over HTTP to tunnel the database requests. Basically you'd use a JDBC driver that redirects the SQL requests to a web server.
A better way would be to refactor your code (I presume that would be a lot of work though...)
If you manage to abstract the data access layer, you can replace it by something more suitable for a web access, for instance a Web Service.
Finally a drastic option is to transform your client/database application into a webapp.
Context: I'm working on Spring MVC project and using Hibernate to generate database schema from my classes using annotations. It uses MySQL server running on my local machine. I'm aiming to get hosting and make my website live.
Do I use mySQL server of a hosting provider in that case to run my database?
What are the pros and cons? Would they normally do db backups or its worth to do that myself and store it on my machine?
Am I going to loose data in case of server reboot?
Thanks in advance. I'm new to this, hence feel free to moderate questions if it sounds unreasonable.
Much of this will depend on how you host your site. I would recommend looking into CloudFoundry which is a free Platform as a Service (PAAS) provided by the folks at VMWare. If your using Spring to setup hibernate, Cloudfoundry can automatically hook your application into a MySql service it provides.
In any case, your database will most likely reside on the hosts server, unless you establish a static ip for your machine and expose the database services. At that point, you might as well host your own site.
Where the data will be stored depends on the type of host. For instance if you use a PAAS, they will choose the location they store your database on the server. It will be transparent to you. If you go with a dedicated server, you will most likely have to install your database software.
Most databases supporting websites should provide persistent storage or be configured to do so. I'm not sure why your MySql database loses data after you restart, but out of the box it should not do so. If your using hibernate to autogenerate your DDL, I could see the data being blown away at each restart. You would want to move away from this configuration.
1 Do I use mySQL server of a hosting provider in that case to run my database?
Yes. In your application you only change the JDBC connection URL and credentials.
There are other details about the level of service that you want for the database: security, backup, up time. But that depends on your hosting provider and your application needs.
2 Is it stored somewhere on the server?
Depends on how your hosting provider hosts the database. The usual approach is to have the web server in one machine and the database in another machine inside the VPN.
From the Hibernate configuration perspective, is just changing the JDBC url. But there are other quality attributes that will be affected by your provider infrastructure, and that depends on the level of service that you contract.
3 Should I declare somehow that data must be stored f.e. in a separate file on server?
Probably not. If your provider gives you a database service, what you choose is the level of service: storage, up-time... they take care of providing the infrastructure. And yes usually they do that using a separate machine for the database.
4 Am I going to loose data in case of server reboot? (As f.e. I do when I restart server on my local machine)
Depends on the kind of hosting that you are using. BTW Why you loose the data on reboot in your local machine? Probably you are re-creating the database each time (check your Hibernate usage). Because the main feature of any database is well... persistent storage :)
If you host your application in a virtual machine and you install MySQL in that VM... yes you are going to loose data on reboot. Because in this kind of hosting (like Amazon EC2) you host a VM for CPU execution, and all the disk data is transient. If you want persistent data you have to use a database located in another machine (this is done in this way for architectural reasons, and cloud providers like Amazon gives you also different storage services).
But if the database is provided, no.. a persistent database is the usual level of service that you should expect from a provider.
Preface: I'm not a java developer.
I have a question about Tomcat / jBOSS and other java application servers. Where are sessions (session data) stored? In PHP, sessions are usually stored in the database which means you can easily share session data in a load balanced environment. In Tomcat and other application servers, session seem to be stored in memory by default which would not apply in a load balanced env. While it is true that PHP stores sessions in files by default, it takes a few lines to hook it up to a DB. Is the same true of applications servers?
Basically, what's the pros for storying sessions in memory? Is this still standard practice for application servers? Thanks all!
I have a question about Tomcat / jBOSS and other java application servers. Where are sessions (session data) stored?
By default, I'd say in memory. Details are actually... implementation details which are application server specific.
In PHP, sessions are usually stored in the database which means you can easily share session data in a load balanced environment. In Tomcat and other application servers, session seem to be stored in memory by default which would not apply in a load balanced env.
Well, not exactly. What this means is that a client request has to be sent to the same node in a clustered environment (this is referred to as "session stickiness") and this is not an issue from a load balancing point of view. But this is an issue from a failover point of view: in case of failure of a node in a cluster, session state managed by the node can be lost. To solve this, almost all application server providers implement session failover (using various mechanism such as in-memory replication, JDBC-based persistence, etc). But, again, implementation details are application server specific. See for example how Tomcat or WebLogic deal with that. The Under the Hood of J2EE Clustering article on The Server Side is a very interesting reading too.
While it is true that PHP stores sessions in files by default, it takes a few lines to hook it up to a DB. Is the same true of applications servers?
As I said, not all application servers will offer JDBC-based persistence. Having that said, and to answer your question, configuration is in general simple when they do. But using a database is really not the preferred solution (actually, I avoid it at all price).
Basically, what's the pros for storying sessions in memory? Is this still standard practice for application servers?
Simply: performance! Serializing data, calling a database, writing to disk, all this has a cost. In-memory replication obviously allows to avoid some overhead. But it has some limitation too. For example, it doesn't allow WAN HTTP Session State Replication with WebLogic. But well, only few people need this :)
With the provided Session Manager, the session is always in memory but it has a manager to persist the session to JDBC store,
http://tomcat.apache.org/tomcat-5.5-doc/config/manager.html
Unlike in PHP, the session is still accessed from memory and it's only persisted to DB when the memory limit is reached or at server shutdown. So your load-balancer must have sticky routing for this to work.
The benefit of in-memory session is performance because db access doesn't occur for every transaction.
You can write your own session manager to simulate the PHP behavior.
The JavaEE spec does not dictate this, it is up to the individual implementations to decide. For example, the usual way to handle load balancing in Tomcat is to use replicated sessions, where the session data is multicast between the nodes. Storing session data in the database is a huge performance killer, and while Tomcat may support it, I really wouldn't recommend it.
We have an infrastructure set up where in the webservers are clustered and the application servers are not. The webservers route the request to the application servers based on round-robin policy.
In this scenario, the session data available in one application server is not available in the other application server. Is there anyway by which the session data from first application server can be made available in the second application ? The two application servers are physically separate boxes in different cells.
One approach could be to use the database - is there any other means of accomplishing this session replication ?
In WebSphere there are essentially two ways to replicate session data:
Persisting to a database
Memory-To-Memory transfers
Which one is appropriate for your needs is highly dependent on your application scenario:
How important is the persistence of your session data, when all your application servers go down?
How many session objects do you have at any one time simultaneously?
In a DB you can store many sessions without much problems, the other option is always a question of how much memory is available.
I would go with the database, if you already got one set up, which all application servers use anyway.
Here is the link to the WebSphere Information Center with the necessary details.
One obvious solution is to enable clustering of your application servers. I assume from the way you worded your question you have rejected this option. Another option is to change the routing used by the web servers to use session affinity (requests for the same session go to the same app server).
Other that that, I'd second the answer by dertoni.
maybe you can look at 'terracota'. its an caching framework, which can cache sessions and runs on a seperate server
There are two options for clustering within WebSphere, session replication or database. If you have large session objects you are best off using database because it allows you to offload stale sessions to disk. If they are then represented then they can be extracted from the database, if you use session replication then those sessions need to stay in memory on not just your target server but also the other servers in the replication group. With large sessions this can lead to an out of memory condition.
With database session handling it is also very customisable and doesn't performance noticeably in the environments that I have used it.
don't forget oracle coherence.