In Scalardb, would TransactionService create a new session every time I instantiate it?
Can I create a TransactionService at application start up and use the same session throughout the application lifecycle?
If the connection breaks, would TransactionService throw an exception which my application can handle and try to reconnect?
In Scalardb, would TransactionService create a new session every time I instantiate it?
Session is always reused once created if TransactionService is properly created with Guice since it is configured to do singleton. (This is also the answer for the 2nd question)
If the connection breaks, would TransactionService throw an exception which my application can handle and try to reconnect?
The connection will be re-established automatically so you don't have to worry about it.
(It is taken care by the datastax java driver)
Related
I have a Spring Boot application with Mongo DB, which is deployed on Azure.
Now if I do not call the API for a long time, maybe some hours and call it my first call always fails with the exception attached. But then it starts to work fine. It seems that the database goes into an idle mode and then whenever the query is made for the first time it is still sleeping hence the error. Is this understanding correct? How to fix it?
Yes, your understanding is correct i.e, the database goes into an idle mode and whenever the query is made for the first time it is still sleeping hence the error occurring.
The above exception is due to the connection timeout.
It closes the connection because of passing the maximum connection idle time.
You will need to set this property according to your requirement.
maxConnectionIdleTime
This can be set either on your Mongo configuration or application profile.
I'm using grails 4 to develop my backend, and I want to control how connections to my MongoDb is logged. Right now, nothing is logged (at least not unless the connection fails). There seems to be a lot going on under the hood, and the whole process of connecting to my database is very much hidden. It seems like the main bean that takes care of this is called mongoDatastore, but is there an easy way to, for example, register a listener for connection events on this bean? Or do I have to extend MongoDatastore and register my own bean?
I also had an idea of using the applicationContext to fetch the bean, and from there somehow register an event listener, but I don't know when or where in the initialization phase I would to that.
All MongoDB 4.4-compatible drivers publish CMAP events that the application can subscribe to. These tell you when individual connections are made and closed as well as pool behavior.
Consider service, which starts some thread inside it. Will Tapestry 5 manage this thread in part of e.g. closing hibernate sessions inside such thread or not? (For example, we can pass Session object inside such child-thread from service. Will Tapestry safely close this session after thread dies?).
Tapestry can only manage things declared in your AppModule.
As a simple rule, if you use the "new" keyword, it's not managed by tapestry.
If you want tapestry to manage your runnable, take a look at ParallelExecutor
If you want to mimic a tapestry managed thread, you must call Perthreadmanager.cleanup() once your runnable has finished.
Hibernate session is attached to the web container's thread which is handling the current request.
If you decide to spawn your own thread and pass to it that Session, then changes to that Session will be committed only if they 're done before Tapestry commits or before the above mentioned web container's thread ends processing that request.
Tapestry's control over the hibernate session is bound to the current request, after the request has been processed the session is closed, so spawning another thread that outlives the request to use the Session would be a bad idea.
Imagine I have an application written using Play 2. Imagine that application needs to grab hold of some things on startup (read a config file, grab some resources from JNDI, that kind of thing). Play handily gives us the GlobalSettings object that we can use to hook into start and stop events:
import play.api._
object Global extends GlobalSettings {
var someResource: Resource = _
override def onStart(app: Application) {
// might throw an exception if the path doesn't exist
resource = JNDI.grabThing("/some/path").asInstanceOf[Resource]
}
}
The problem is - what can we do if the initialisation fails? It seems that this is only executed when Play receives the first request for the application. If we throw an exception, that causes that request to fail, but the application keeps on running.
Ideally, what I'd like is to stop the application from starting at all if this block doesn't complete successfully. Unfortunately, calling Play.stop() doesn't actually seem to, well, stop Play. I can see that the Server trait defines def stop(), which looks promising but I can't figure out a way to get hold of the Server instance from inside my application.
Perhaps I'm looking at this the wrong way, and I'm not supposed to be able to stop Play (or even just my app) from inside my application, so suggestions for other approaches are welcome.
What's the best way to handle these errors?
It seems I'm lying. Play only continues to serve requests after an exception in onStart if you're running in dev mode (play run). If started with play start (i.e. production mode) an exception here will terminate the server, which is exactly what I wanted.
It does appear to leave the RUNNING_PID file lying around, which is irritating, but that's a separate issue...
I have a Workflow Activity to handle task operations. The flow of the activity is "Create->Detach->Accept->Finish". A new workflow instance will be created for each new task. And the unfinished instances are persisted into database.
And after several days I change the activity, append a new step "Verify" at the last of the flow, so now the new flow is "Create->Detach->Accept->Finish->Verify".
I found that I can't resume the persisted instance by the new version activity. While I attempt to load the persisted instance, an exception thrown. How can i resume old instance by the new version activity? I want that the unfinished task can be handled by the new flow.
Unfortunately there isn't much you can do about this in .NET 4. Soon in .NET 4.5 there are new APIs that will allow you to update the persisted instance to prevent this.