Let me explain my scenario...
Say I have two table: "Paths" and "Packages"
Paths table is consists of "PathId" "StartNode", "EndNode"
Packages table is consists of "StartNode", "DestinationNode", "Paths"
I am going to write a program which compute the path that route a package from start to destination, using whatever shortest path algorithm.
In order to make sure the paths settings are not changing while I compute the path, I believe I should use "SELECT * FROM Paths FOR SHARE" to obtain a share lock. So until the paths are computed and transaction is committed, the path start/end must not be changed, and at any point - the computed paths in the database is always valid.
The question is: I am writing the program C# with NHibernate, how do i get a share lock?
I have tried:
Session.QueryOver<Path>().Lock().Read.List()
but it does not do the magic.
Is Session.CreateSQLQuery() the only solution?
As far as I know NHibernate does not currently support SELECT...FOR SHARE, but it does support FOR UPDATE and FOR UPDATE NOWAIT (see lock modes), which is of course more strict, but it would work.
Since NHibernate is an open source project you may suggest this enhancement and of course implement it.
Related
I'd like to know how to configure the location of ObjectStore for JTA. My target is Helidon MP.
Currently directories named "ObjectStore" and "PutObjectStoreDirHere" are automatically created under the current directory. Also I'd like to make sure if we really need two directories in order to manage transactions.
These directory names are the default names for certain directories provided by the Narayana transaction engine, which underlies Helidon's JTA support.
I am not a Narayana expert, but from looking at their source code, it appears that at a certain point they are going to construct an instance of ObjectStoreEnvironmentBean. As you can see, it has a getter method called getObjectStoreDir(). Ultimately this is going to give Narayana the name of the object store directory.
Now, how does this get populated? Again, from looking at the Narayana source code, it appears that this instance will be populated by way of something called a BeanPopulator. Specifically, the BeanPopulator will acquire a default set of properties, and then apply them to the bean under configuration—ObjectStoreEnvironmentBean in this case—and that will provide the name of the object store directory (among other things).
OK, fine, but where do these properties come from? It appears that the default set of properties is located (ultimately) by the AbstractPropertiesFactory class. Specifically, its initDefaultProperties method is going to look for an XML file of a particular kind and load it.
What kind of XML file will it look for? It looks like if there is a System property named com.arjuna.ats.arjuna.common.propertiesFile, that resolves to the path of the XML file in question, it will be used. If there is no such System property, then we can see that the return value from ConfigurationInfo#getPropertiesFile() is used instead.
Somewhat bizarrely, during the build of Narayana (!), that method's bytecode is replaced (!) with a recipe that comes from the pom.xml, and finally there we can see our answer: the return value of this method will be, exactly, jbossts-properties.xml.
That is, of course, a relative path of some kind, or perhaps a classpath resource. Which is it? For that, we have to return back to the AbstractPropertiesFactory class and note how that name is used. We can see that it is sought in various locations via the FileLocator#locateFile() method. The FileLocator#locateFile() method first tries to treat the name as an absolute path (clearly we can see that jbossts-properties.xml is not an absolute path), then as a path relative to the user.dir, user.home and java.home System properties in that order (almost certainly this will not exist either), and finally as a classpath resource. So there is our answer: jbossts-properties.xml, if present as a classpath resource, will be used as the source for where the object store directory should be created and located by Narayana.
Now, what does this XML file look like? It appears that an example file can be found here: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/narayana-jta/src/main/resources/jbossts-properties.xml. You can see that something like this is ultimately where PutObjectStoreDirHere comes from. So I think if you set one of these up in one of the locations detailed above you can get the object store put in whatever place you want.
Things get a little weird, though, because while this answers the question of where PutObjectStoreDirHere comes from, it does not seemingly answer the question of where, simply, ObjectStore comes from. We can see that this appears to be the default value of the objectStoreDir bean property if we look at the source code of ObjectStoreEnvironmentBean again, so my guess here is that there may be some other property involved.
As mentioned before, I'm not a Narayana expert, so it might be best to get in touch with the Narayana folks to find out all the details about all the edge cases here.
According to the Narayana documentation, you can set one of the following system properties.
ObjectStoreEnvironmentBean.objectStoreDir
ObjectStoreEnvironmentBean.localOSRoot
as in
java -DObjectStoreEnvironmentBean.objectStoreDir=/tmp/whatever -jar my-helidon-mp-thing-that-cant-tell-jpa-and-jta-apart.jar
But that only really moves the "PutObjectStoreDirHere" directory. The "ObjectStore" directory is hard coded in Narayana to this:
private volatile String objectStoreDir = System.getProperty("user.dir") + File.separator + "ObjectStore";
And there's no good way in helidon/CDI to plug into the initialization cycle and call ObjectStoreEnvironmentBean::setObjectStoreDir so, we just have to live with that.
The bigger question to me is, why do we have to have some noisy JTA implementation when really all anyone want's #Transaction to do is open and close a transaction. JTA is really not a value add here, or anywhere really.
I'd like to specify the database schema for a query by comment. I know that you can do it for files in the settings of intelliJ. But since this information is stored in the intellij configurations (I guess) which aren't shared in our company through git, those information are lost when the project is shared through a VCS like git. And so would other people not get correct validation of the queries.
What I'd like to do is basically something like this:
#schema=foo
SELECT * FROM bar;
Which would be the same as if you write:
SELECT * from foo.bar;
For what? Basically just for code completion and validation from intellij that your query is correct and has no syntactic or logical errors. Does anyone know if there's a plugin or hidden functionality? I searched around google but didn't find anything.
E: Nice would be if you can specify those comments for the whole file or only for single queries (first one would be better, second optional)
E2: It maybe looks strange why I don't just write the second example with the schema. But if I don't write that I can load the file to e.g. java and specify the schema dynamically in my source code through the database connection.
Just use appropriate "use statements" in sql file/console. IntelliJ IDEA honors them when doing resolve, and code completion. This is implemented so that you would have the same experience when executing the sole script or within IDE. This way the script will be valid from both points: stand alone execution and IntelliJ IDEA intellisense.
I am attempting to manage a repository's index vs. its HEAD tree using libgit2 (via Objective-Git, but I'm increasingly finding myself heading down the vanilla libgit2 rabbit hole), and am wondering what exactly the flags_extended field's bitmasks on git_index_entry struct actually mean. Additionally, when are these flags set? I've been digging through the libgit2 source, but cannot seem to find where flags_extended comes into play.
The reason I ask:
I have a simple test repository with one commit containing some simple test files. The working copy has one tracked file with a minor change and one untracked file, both of which have been staged externally (git add . on the commandline). In my application, I need to "unstage" the files, so I fetch their respective git_index_entry structs. I was expecting the flags_extended to have GIT_IDXENTRY_UPDATED set for the modified file and GIT_IDXENTRY_ADDED set for the previously untracked file, but in fact both flags_extended fields are empty, which is what prompted this question (the only thing set is the GIT_IDX_ENTRY_NAMEMASK in the flags field).
I can certainly fetch the HEAD tree and compare the entries with the entries in the index, but I was hoping that libgit2 was already providing that info via the flags_extended.
I was expecting the flags_extended to have GIT_IDXENTRY_UPDATED set for the modified file and GIT_IDXENTRY_ADDED set for the previously untracked file.
No, these flags are fundamentally internal to libgit2. They are used to maintain the information about index entries in-memory after loading the index from disk. They are to prevent and/or detect internal data races, they are not for determining the status of your repository.
If you want to compare the HEAD to the index, load the HEAD tree and then use git_diff_tree_to_index.
Supposing I have a merge module that installs a file "MyFile.txt" to a certain location, and that I wish to use that merge module, however I want to supply a different copy of "MyFile.txt" from the one supplied with the merge module.
Is it possible to do this? (And for bonus points how can I do this using Wix)
Update: Roughly speaking MyFile.txt is part of a package up component of installable items that we provide to others, they then comine these components with their own to produce an installer.
In the ideal world they would only need to add new files to the output, however this is a replacement for an existing system where they currently have the ability to modify or even replace items (suce as MyFile.txt) in the end installer, and so without the ability to do the same with the merge module the migration path will be difficult.
The packaged up component doesn't need to be a merge module if there is a better solution, however merge modules seemed like the sensible choice and in all other respects provide a very nice re-usable package of installer logic.
It's possible but every technique that I know is a bit of a hack and doesn't scale very well. Can you tell me more about what type of file MyFile.txt is and what the intent of the different flavors of the file? Usually my goal is to never have the same filename twice ( darn component rules ) and then design variation points to support the needs. Sometimes upstream changes to the application are required to do this correctly.
I've inherited a collection of largely undocumented ssis packages. The entry point package (ie: the one that forks off in a variety of directions to call other packages) defines a number of variables. I would like to know how these variables are being used, but there doesn't seem to be an equivalent of "right click/Find All References"
Is there a reliable way to determine where these variables are being used?
A hackish way would be to open the dtsx file in a text editor/xml viewer and search for the variable name.
If it's being used in expressions, it should show it and you can trace the xml tree back up until you find the object it's being used on.
You can use the bids helper add-in thats gives you visual feedback on where variables are used in your package. Thats makes it very fast and easy to detect them.Besides that, it offers several other valueable features.
Check out: http://bidshelper.codeplex.com/