Paul Clapham wrote:Good to hear that!
As for "what happens under the hood", that isn't what you need to know. You need to know how variables work in Java. Here's a link to a pretty decent tutorial which tells you about that: Variable Scope in Java.
And then you say that some other code tries to use some other value, and it's null. Right?
Tim Holloway wrote:You confused me. I call "DML" SQL. Since basically, DDL is the part of "SQL" that isn't actually SQL and SQL is the part that was defined by Codd and Date.
Anyway, as I recall, auto-commit is on by default with MySQL and PostgreSQL and probably Oracle, SQL Server and DB2.
Realistically, saving stuff up to do a commit is something more common to programming than for just fiddling around with the database manually, so I'd expect auto-commit to be the default in general.
But I don't think that it's actually mandated anywhere. For that matter, I don't think that there's a standard that says a DBMS even has to have a command line interface application. Although it's going to be a lot less fun tweaking things without one.
sorry but, I got confused.
DDL is the part of "SQL" that isn't actually SQL
Tim Holloway wrote:Actually, while it might vary depending on which DBMS you're using, I've always seen DDL auto-commit. And actually, having to explicitly commit DDL sounds a bit problematic to me.
Paul Clapham wrote:
Kirk James wrote:Injecting static fields looks like a wrong usage of an OOP pattern (dependency injection), also static fields belong to a Class, not to an Object;
Those are both good reasons not to inject static fields, so I think you have the answer well-covered.
Rob Spoor wrote:Consider you have a microservice that you use. There is one instance deployed, and you talk to that directly. After a while, your demand increases and a single instance just can't cut it, so you add a second instance. However, now you must change your application to support both instances, or put a load balancer (Apache, Nginx, etc) in front of it. You can do that, but once you need a third instance you need to go through this process again. (If you use a load balancer, you must update its configuration).
With service discovery, each instance registers itself. Your application is a client of the discovery service. When it needs to access the microservice, it asks the discovery server for an instance to talk to. You don't need to configure all the separate instances, only the discovery service. If a new instance is added, it registers itself again, and the discovery service will automatically make it available for you.