Lou Hamers wrote:
Yes that's why I like to call it ML instead of AI. But I still end up using the "AI" term sometimes, because I guess we already lost that battle. EVERYONE is calling it AI and most people don't know what "ML" is. Intelligence means thinking, to me, and this software isn't doing that.
Lou Hamers wrote:
My main worry about this stuff currently is that it ends up too centralized and controlled. I'd much rather see it open source, accessible to all for a low cost, and hosted locally without needing to rely on some corporate spy company. Theoretically that would help level the playing field for the little guys against increasingly powerful and wealthy organizations/people.
Lou Hamers wrote:Makes sense, but I hope whatever's written in Python gets implemented in other languages eventually.
Tim Holloway wrote:It's what those third hands are touching that make me hesitant. And the funny fingers. We're still learning about machine learning.
Tim Holloway wrote:Just to be clear, I'm taking it as a given that you're NOT attempting to do any sort of threading here, that these are, in fact, multiple concurrent client requests. Because although it may not be apparent, most of the business logic in a Spring Boot app runs under a Servlet or JSP and both of those are absolutely forbidden to spawn threads.
Tim Holloway wrote:
As far as database locking goes, my understanding of Optimistic Locking in JPA is that before an update is posted the JPA infrasstructure does a fetch of the affected record(s) and checks to make sure no one has modified them elsewhere, throwing an Exception if they have. Been there/done that.
My own database logic, which I've often mentioned elsewhere on the Ranch has essentially 3 layers.
* The Entity Layer, which (surprise!) defines the table and View Entity classes.
* The DAO Layer, which is primarily concerned with CRUD and finders for individual tables, or tightly-bound parent-child table pairs. Lately Spring Data's repository feature has supplanted a lot of the brute-force logic for me.
* The Service Layer. This layer works on a "working set" of related records (a directed graph). It detaches the graph from the JPA system before returning a fetched set to the higher levels of the app and it re-attaches (merges) when the business levels request a Service method to update the datastore. The Service layer delegates its dirty work to the DAOs.
Both the Service Layer and DAO layer classes are marked @Transactional,wwhere the DAO transactions get adopted into the transaction of the service that uses them (I forget the exact name of that option, though).
Tim Holloway wrote:
Once a Service is bound in a Transaction, it will either queue behind other Transactions or throw a locking Exception if it cannot otherwise resolve matters. In the case of a lock exception, the service is going to have to re-think its own changes to whatever Entities had conflicting requests and resolve them before trying again. Which sounds intimidating, but isn't something I've had many problems with.