 All right, so This is an important topic to address the the importance of Java and Postgres and It seems like this is this is gonna be interesting giving the numbers I'm gonna show to you later that there seems to be not really much interest in Postgres in Java Which is one of the topics I want to cover here today Hopefully you you might be as as I am So We're gonna address what was what's been the past so far of Postgres and Java Where we are at right now and what I in a really humble position think that the future might be It's just a little bit before starting. I wanted to introduce myself Salam already said Alvaro in Spanish or Alvaro if that's easier for you to pronounce I work for a company called 8k data Tried to figure out what's the meaning of the name of the company Especially being on a postgres conference. It's not a really difficult Other than that we are an R&D company. So we we do research on crazy stuff Some of that stuff happens to be toward DB. It says no sequel database It that is compatible with MongoDB then runs on top of Postgres and Performs a no sequel to sequel transformation and all these by the way is then in Java So based on this experience is part of the reason of this talk. Where are we focusing a lot on postgres in Java? and We're also part of the postgres community from a long time. We're the founders of the postgres Spain which has become since It's inception the fifth largest postgres community in the world with over approximately like 600 people right now If you want to talk to me after the conference, I'll be around till tomorrow But you can also find me on Twitter or LinkedIn or whatever. So Let's get started postgres and Java two key technologies in the enterprise world nowadays and they let's see how they play along together and What it's about this So some statements first Java is the enterprise language So this brings me to an interesting point here Like how many people attending this conference are paying attention to the you know focusing on the enterprise market Might not be as hipster or as sexy as other languages nowadays, but this is the fact the de facto enterprise language, right? So Indeed as the slide says there might be more code accessing postgres from a Java programming language than any other language So it is important as a community that we understand the importance of Java Most of our users are probably Java, but we want to turn it out. That's that's what it happens, right? And and both are mature and reliable technologies that you can trust upon. So it looks like a good combination So it's probably a safe bet to bet on postgres and Java at the same time If we look at the popularity And this is what I wanted to show that looking at the numbers it looks like Java is an extremely popular language Sure, there are different indexes. There are different ways of measuring popularity. All of these are probably imprecise methods Now it is surprising that not only it is the most popular language nowadays But this peer popularity is increasing over the time. So it's getting more and more popular If we look at the numbers on this month April 2016 Java it's not according to this index that I over index which is probably one of the most precise ones based on the This company do which is an analysis of millions of lines of code every single day for many customers So they look at the numbers they have real numbers, right and they came up with this index and if we look at it It turns out that Java There's a distance of almost eight points to the next popular programming language and This distance has been growing In the past it was less than eight points. So Java is increasing its popularity It wouldn't be fair to just look at one number So I try to look at some other numbers and try to spot also this this trend And if we look at github and github definitely is a place for hipsters, right? So if we look at hip github Java started like very low like in 2008 was in seventh position in the rank But if you look at the trend Java is this blue line It's been growing and growing and growing and growing now It's the second most popular language in github the history place. Of course number one is JavaScript But that that's been almost all the time since the beginning But this can show that even in the open source again, sorry for insisting on that term hipster community Java is becoming a very popular language That's probably it's a little bit counter-intuitive because most people would say it, you know Postgres for new open source projects is not a good choice, but it is at least in terms of popularity Last but not least there's I took a third Index to try to see if this is a common trend common opinion among among people that build popularity indexes And it looks like again Java is again number one did the second and third players are different in this index done from the previous ones But anyway, what we can conclude without any kind of doubt after looking at these three numbers Is that Java is either the first or the second or I mean It's among definitely among the top three programming programming languages in the world so Going back to my initial point. We need to really pay attention to Java In the postgres community because it's real important might be the most important language for for us to interact with So let's look at the past because of course looking at the past is a nice way of understanding where we are and What the mistakes were and how we can improve on them, right? so in order to prepare for this talk we need some analysis and and Some questions about key players in Java and postgres in the past to see What they thought about the technology and these are some of the conclusions that we can came up with So the first thing is that there seems to be like an impedance mismatch between postgres and Java first of all postgres is reading C as a C which is a Language where you basically manage the memory by yourself Whereas Java is a completely different parting in terms of programming where memory is more or less managed by you by the JVM and This brings a complete different model. So Many programmers that are comfortable on one of those models are not as comfortable in the other and this creates a difference all the languages don't have these properties for the good or the bad and are more close to the postgres model Then there's also something else which is Java requires a JVM to run the code And this also brings another difference because postgres and C code just execute a binary and that's it So just think about terms of community It turns out that there's not a lot of people in the postgres hacker community. I mean the people that develop postgres that either use Java or know a lot about Java Because they happen to be different models different memory models different execution models and of course different language So as long as as this is a big difference it creates a Varier for doing Java development for postgres because few people know Java or are experts in both sites both postgres and Java So it is a it is a big problem. It was also the perception that Java is slow That was definitely the past. I wouldn't agree with that now in the present However, you may you may diverge right? So how many of you do you think Java is as low? to sort of Okay, I would agree with that. Yeah, it it's loaded and Depending on what you do and how you do it might be slow might be really fast. I mean Java is also used on high frequency trading which are among the most Intensive and latency sensitive environments Yet you have to do a lot of tricks So it can be fast, but it can also be a slow So What technologies do we had in the past in terms of postgres and Java? Well, first of all, we have the PG JDBC This is the official driver the JDBC driver. It's been here for a long time. It's a type for driver You mean, you know what the JDBC types mean? Basically a type for driver means that it's a native driver the driver implements the postgres protocol So this driver speaks the postgres protocol They call the Phoebe protocol front-end banked protocol and it speaks it and natively. There's no conversion no practice in the middle There were some lessons learned like when I was interviewing the original PG JDBC developers But what went wrong when they started this project? the most Agreed comment was that postgres as a community was not involved in the process of the defining the JDBC spec and This has turned out to be a big problem in the present because Many goodies many features that postgres has there are kind of unique to postgres Are not present on the JDBC spec So there's a lot of stuff that if you want to take advantage of postgres You have to go around because there's no support in the JDBC spec for that Like for instance the Colby protocol The fast way for data ingestion or export from postgres. It's not supported in JDBC because it's not part of the JDBC spec so in order to work with the Colby protocol in postgres you need to to to basically Break out with the standard and use postgres specific methods. There are supporting in driver, but they are not part of the spec So you're going out out of JDBC Same goes to Jason support Though there's no specific Jason support on the driver yet But other than that, there's no support in spec if we could have Form part of the process of creating the spec we may have influenced that in some way or another But there wasn't the case All the problems that were kind of acknowledged was the lack of a row ID in postgres Which is present on all the databases which made things like very simple to develop and it wasn't possible because there's no that kind of support and also kind of a big mistake was the use of the of the question mark saying in in in the Prepared statements to mark parameters for the prepared statements because the question mark is also used as an operator in postgres in the sequel language in many cases, so Makes it a little bit awkward now to create prepared statements Which also use this question mark as an operator because you have to escape them. So That was PG JDBC Then there was PL Java. So by the way, who uses here of have used JDBC PG JDBC Yeah, most of you right. What about PL Java? Well, right Okay, okay, so PL Java was a very interesting idea It started like very strong There was a lot of heavy development going on and then at some point it kind of faded away The idea of PL Java is to be able to run store procedures reaching in Java So you can call a function In and it will be programmed in Java The way it would work the model that PL Java works is having a JVM That will be fired when you Call the first function So calling the function will fire JVM will execute the Java code all Java codes stored in static functions and You're good to go Problem is that firing a JVM per invocation of a function call is a little bit expensive, right? Someone mentioned. Yeah, but it's a little bit bloated We'll see with Java 9, but that's a different story So good news is that PL Java supports caching the JVM per session. So if you make several calls per session JVM will still be cashed there. So it's a good option So you really need to take care about whether to use it for like latency sedative applications or or you're good with this Kind of caching behavior throughout the session It has a JDBC API good news is that J this JDBC API is not going over the network Rather, it's using the SPI SPI is an internal API for Postgres for calling Calling basically the database So it uses GNI to transform from the SPI interface, which is a C interface to JDBC Good news is that this is completely hidden for you. So you just write normal JDBC calls and In in the behind in behind scenes this will be calling the database directly attached to the Really? Oh, okay, didn't No, not at all might be an implementation detail I didn't know but Okay, okay But at least theoretically they they wrap. Yeah, they wrap SPI which should be pretty efficient in terms of accessing the database At one point PL Java offered support for GCJ The GNU compiler for Java. This is completely deprecated by now It only supported Java one point one point four and that was compiling the Java code to native code and didn't require JVM But this again, it's also faded away trade-offs by using PL Java as long as there's no up kind of a permanent JVM running all the time if you need kind of Persistent state you could either save the state to the session So there's a concept of a session in PL Java which lasts your connection If that's enough for you, you're good to go because you can store stating memory attached to the session if you need to attach a state That should survive across sessions The only thing you can do is use a database fortunately have one close to you So that's the only way but you have to write it to your ability to disk to the database There was another effort called PLJ Any of you has have used PLJ? Okay, one PLJ was it was it was surprisingly coming out at the same time of PL Java more or less and The idea was complete different. So rather than firing a JVM per method called invocation and then cashing it later The idea is like let's just fire JVM at the beginning and then keep it running and then let's call that JVM This of course brings theoretically more performance because you don't need to start new JVMs all the time But at the same time it has a problem that there's the there's a lot of security concerns with that with that model Because then many users could use the same JVM JVM is like shared. So you have to create like a multi-tenant JVM Some of the databases by the way have followed this approach like Oracle Oracle has a have to say very impressive JVM running alongside the the database and it's kind of a Multitenant JVM where the garbage collection happens per user. So it's the kind of a separate heap per user There's a multi-tenant JVM. It's pretty impressive. So this was more or less without the multi-tenant garbage collection mechanism That was the intent of PLJ The problem with PLJ is that there was a really heated discussion in the mailing lists To so as to which solution to include in core whether a PLJava or PLJ The end result was that none of them Got included in core. Just wasn't a really good solution. But that's where it happened so that was an analysis of the past and The lessons that we have more or less learned about this Let's look at what do we have here? What is it present? So there's a lot of Java text that we can talk right now First one is the JDBC driver itself, which we have already mentioned So this driver the good news is that it's in a really good shape right now It was a development was a little bit stalling in the last years the traffic in the mailing list went down and it was like not very active under development and Performance was honestly not great But in the last one two years things have changed significantly a lot of new both has come into the group and new developers are Developing PG JDBC. It's the build mechanism has been switched to from aunt to to Maven. Thank you There was a big heat is moved to Github and it's been modernized What it's more important is performance has improved significantly. So If you're using older versions of JDBC and By older if you look at the numbers they don't look like you're too far away from the current version I really encourage you to try first and of course and then upgrade to the newest versions like Who's running here version prior to 1200 like You know, which versions are you running? JDBC No Well, I mean you really have to look for the latest versions Like 1247 or so. They are really really much better performance than then they were previous versions So just have a look at those which versions are you using you you may see a big performance improvement It is of course a very reliable choice It's been the de facto way of accessing Postgres from from the driver So it's it's good which good choice, but it's not the only one There's another Java driver, which is called the next-generation driver the PG JDBC and G Name is a little bit awkward to pronounce The idea is to build a completely new driver. It's a still a JDBC driver. So it's following the JDBC spec But the principles under which this new driver will build were more modern and complete different So the first idea of PG JDBC and G which I'll call now and G to make it shorter is to First of all not support old versions of Java old versions of Postgres And all versions of the protocol because those three legacies are a significant amount of the code base for the JDBC driver so by just focusing on newer versions of Postgres Java and and Protocol you could you could get rid of a lot of problems and all on all legacy Then rather than implementing the wire protocol From scratch because then it's against the time for driver, which means that speaks natively the postgres protocol it used neti which is an Network IO as in IO framework, which is great for implementing network protocols So it uses neti to simplify it to be more performing on the network layer and then it supported only Java 7 with with all the goodies that come with Java 7 to implement, you know more More easier code Again, it also started like very strong and achieved a lot of milestones in the while development is a little bit Tall I would say I wouldn't say it's tall probably because it's going on but it's definitely slowed down Latest release was 0.6 in October last year Though it's still a good driver. I think it needs to still need some more mature Development But it's a really good option. There are all the drivers There's a type 5 driver from progress. I don't know. Do we have anyone from progress here? No, okay. So this is mostly a known driver Few people know this driver in the community. Any one of you have ever heard of this driver before before? No, okay. It is a type 5 driver Which if you look go to Wikipedia, you'll see there's no definition for type 5 JDBC drivers, so it's kind of something something above what it's a type for I don't know exactly what it means But well, it's it's a commercial driver and I've seen few commercial projects using it. So that's an option seems to be a fairly complete driver I have not any personal experience with it There's another Postgres driver, which is the Postgres async driver This is very interesting part project because it is the first known JDBC driver So this driver does not follow the JDBC specs it rather has its own API and It's meant to be completely async. So the idea is JDBC if you really look at the spec everything is synchronous operations and Nowadays programming models are mostly focusing on async programming There's and the JDBC spec really limits you there. So in order to to break free and and be async You need you basically need to come up with a new API. So that's what this driver did This is a non JDBC driver. It's written in Scala and it also supports my sequel. So it's it's kind of interesting driver It is also based on neti This network icing IO framework that I mentioned before to implement the protocol both the postgres in the mysql protocol And it's under active development right now So as you can see there's a lot of drivers. There's even more drivers available for postgres There's another one called the RX java JDBC driver There's another kind of mix. It is a JDBC driver. So it follows the JDBC specs So again, you can program with a new API. However, all those calls have been dropped in async methods and Has used their RX java framework of how many of you have used RX Java here? Okay, so only two here You know where it's reactive, right? There's new programming model new programming parting based on composable events to how to rather than then You know query for stuff just react to events that happen in this case The event could be the database pushing data back to you as a result of a query so RX java is a framework for reactive programming and I love it. It's real cool And it's very powerful and it lets you express like type of Callback stuff in a very nicely manner and you can compose operations You can change callbacks on top of callbacks in a very simple manner No need to you know to create nested stacks of callbacks and callbacks and callbacks. This is very easy to use So RX java JDBC is a JDBC driver built with RX java that drops the synchronous JDBC calls into a synchronous calls and Make it and make them easier to to use for the for the user It's JDBC generic. So it uses a JDBC driver underneath so it can work with any database and of course that includes phosphorus So as you can see now in the present There's a huge variety of drivers that you can choose from We did some benchmark to try to compare some of them It's not complete yet. So we don't have numbers for most of the Drivers, but we did test the what is called the official driver and the ng driver Despite the ng driver meant to was this having been designed as a more performance driver our own tests Your mileage may vary of course show that as of today And especially due to the Significant performance improvement that the official driver had it's performing better the official driver However, both are are probably again really good options. This is this is the execution time. So less is better So in all our tests the official driver performed better than the ng driver All right, more good news about the present PL Java PL Java. It's making a comeback so It got active development some two years ago more or less and It just started again and now we have version 1.5 which was released a couple of weeks ago a little bit more So now we have PL Java 1.5. It is a very decent release and It's been modernized Mavinized and supports Java from version 6. So I really suggest you to give it a try I think it's a really great improvement that we can have now PL Java again Some best practices for you. First of all really be aware of all the tutorials that you can find on the internet about JDBC they're mostly updated they contain a lot of code that it's wrong. They don't usually treat exceptions. Well They told you like you have to use class for name to load the driver. That's no longer necessary if you're using Modern Java. So just just be aware of those Just follow these practices best practices. Don't load the driver. That's not necessary since Java 6 Use with try with resources if you're on Java 7 or more than that, which you hopefully are Carefully check all the exceptions JDBC is is full of the exceptions and they're meant for something Despite you like them or not. You have to check for them and of course use prepared statement statements I did a presentation a couple of years ago at Pitchicon in Ottawa Tutorial about Postgres and Java with a lot of source code and good practices Go to this link if you want to to follow those or check those make the best practices What else our amps So Yeah, don't really get me started on this Despite being a long topic I have a really strong opinion about them but Suffice it to say that if you really Really want to use Postgres Postgres has a lot of functionality has a lot of a lot of features a lot of Advanced SQL and most ORMs either hide this from you because they target the lawman lowest common denominator of all the database They support or you have to do SQL by hand in order to to leverage those possibilities So that's that's gonna be at the end of the day limiting your your power with postgres However, good news and this is of course my favorite might be wrong. It says my opinion I have a good solution for you. It is called you. How many of you do you know Duke? Okay, few of you You kiss a mapping layer from the database to Java programs and it's meant to first of all It's not an ORM per se from a literal definition. This is the mapping software. However, it's it's good enough To first of all leverage SQL so it's meant this it's meant to have all the SQL all the power you can have with SQL on this framework and It also uses a syntax, which is a fluent API which really resembles SQL So if you look at this screenshot the left is the SQL's written query written in SQL The right is pure Java code that compiles that it's aesthetically compiled to verify by a compiler that it's correct Even the table name and the columns and it really looks like SQL So just give it a try. I think it's one of the best ways of right now doing SQL from from Java we use it for for ToroDB for instance and the future Because we have like 10 minutes left, right? Okay, so what is in the future for us and please I know this is being recorded. Don't take is This is just my opinion my view might be completely wrong It's usually most people who talk about the future in technology fail miserably So don't watch this talk two years from now and say hey, you were completely wrong might be but let's see some predictions First of all, I expect JDBC driver the official one and the next generation driver to improve significantly Especially the official driver. There's a lot of manpower behind right now So I expect this gonna get more stuff done more performance and new features So I believe it's it's it's gonna be in good shape in the future I'm really pushing right now to get binary support for the JSON be type in the protocol Right now Both Jason and Jason be types the Jason types that Postgres supports are sent as text over the wire Which is pretty shameful Really, it's it's a shame. We have a serialized format binary format in the in the back end and As Java users we also understand this kind of graphs and objects or hierarchies and code And then we marshal and a marshal everything from to text We contrast this with all the databases like I'm going to be They they send Dejacing documents in another format, which is another binary format, but it's it's already parsed and sent as is over the wire It could be an improvement for Postgres. It's been already suggested in the mailing list It's not been even agreed yet on which format should be serialized to Jason over the wire But I believe this is something could be done and should be done and and many Java users are claiming for that. I Also think there's a PO Java Renaissance. It's it's gonna come back PO Java strong and it's a really good thing like There's a lot of use cases for like PO Java I've seen some customers that want to do like really heavy operations on XML like for instance Yeah, it's now nowadays Jason is everything. There's a lot of people is still using XML over there and Java has support for excellent XML Libraries which can do like magic even more than what you can do a chief on Postgres alone. So it's like really good use for these kind of things Maybe peel Java or some other forms of Java inside the database may also have a comeback because there's a lot of interest also in running Running Java in my company. We're also working on a project is just in first steps But it's meant to have to launch a Java JVM as a background worker So you can have a permanent JVM running alongside Postgres Which could connect to Postgres and execute Java code not tied to particular session or a particular function invocation So PLJ or some other form of a JVM running alongside Postgres may also see another come back in the future Well, at least we're trying that too And Finally, I want to introduce you to some project. We we also started working in our company. It's it's in a work it's definitely a work in progress and might be interesting for you the idea of Phoebe which is The Greek name of a God, but it's pronounced like the same way as the Postgres protocol the front and back end protocol It's an idea of a new driver yet another driver for Postgres The reason behind this driver is that current drivers, especially the JDBC drivers are limited to what the JDBC spec says Just what I was explaining you before right? We couldn't influence the JDBC spec So there are many things that Postgres does that the JDBC spec doesn't do so there are no supported in the driver And one of the things that we want to implement in a driver is support for logical decoding So, you know what logical decoding is in Postgres Let's see some some heads So logical decoding is a way it's a functionality that was introduced recently in Postgres to basically Create a stream of Logical changes that happen to the database So whenever you do an insert and update and delete to the database and absurd now, right? All that can get logged to a let's say text format to a SQL query format to whatever format you want And that will get streamed out of the database So you can use that to replicate to other databases to other data stores For replication for many other purposes for online filtering of the information for real-time applications has like many uses and There's no support logical decoding goes over the Postgres protocol So it has that you have to understand the Postgres protocol in order to consume this stream of changes And there's no support in the Java drivers for doing so So one of our goals was to support this logical decoding and other features in order to do that we needed to speak the Postgres protocol and As soon as we started implementing the post which protocol we found that we can at the end of the day build a new driver so Phoebe is a new Postgres driver. It's still working progress. It's not working right now But feel free to join us It is async and reactive by the sign So it's based on our ex Java and the idea is that every operation that you perform with the database against the database It's going to be Reactive so you will basically define the operations that you want to perform upon Events that happen with the database that could be a query could be a logical streaming Logical decoding event like you know some data was changed on the database and you say hey I want to run this code upon this event happening on the database It also targets clusters not individual servers So we want to bake into the driver the functionality to to basically say hey I mean, we're we're never we're no longer alone. So postgres databases usually part of a replication Set or or or a shorting cluster or whatever. So the idea is you could target more than one server from the driver It is also based on netty. I believe net is one of the best Java software libraries frameworks available in the world, especially for network icing icing IO operations and Makes it very easy to implement the postgres protocol the wire format protocol And one cool thing is that by design we're doing the most of the operations to go Off-hip memory to use off-hip memory. So this basically turns Java into a memory managed Software and it allows us to be really efficient and to avoid many copies of memory Between the driver the program user and the network So basically we're doing zero copy. We're trying to choose zero copy from the network to the Java driver to the application Some of the expected features that we want to target are use the binary protocol by default You know the postgres protocol supports the text format and a binary format We want to support the binary mode support unix domain sockets. This is yet unsupported in postgres Support as I said logical decoding Support also query pipelining The ability to launch several queries in a kind of a pipeline and then collect all the results asynchronously after that Fully asynchronous operation, of course To say to have the ability to easily express with an API. Hey, I want to send this query out to several servers and If you're targeting a postgres cluster with a read write master and several Secondary slave nodes which are read-only So if this is a read-only query send it to the slaves if it's a write query send it to the master So just send this query to the cluster and the software will choose where to launch it And of course have a really fluent style API a modern API like it's very easy to use be compatible Also with with Java 6 though. This requirement might be dropped But so far is compatible with with Java 6 this is how the API looks like It's subject to change But the idea is that it's very easy to use and it's fluent like like in this Alliance of code you basically say hey create a new rx to postgres client Connect to two servers first one is in on IP version 6 on local host on this board The other one is also on this server local host on another port Get the connection to all host because you can see also get the first one available See you fire the connections and return the first one in this case I want to let's say use all of them and then in it the driver and then I say hey Unconnected which means basically when the driver connects when the disavent fires run this code So I subscribe to the unconnect event and then I just print the connection information This is very basic You don't even do a query with this But I want to show how easy it is to connect to several clusters several servers synchronously select the number of servers You want to connect to and react upon connection? Again this is working progress as this is open source. It's in github postgres licensed feel free to join us developing this and this is pretty much about the Talk I believe we have some minutes for some questions Okay questions there was one over there. Okay, so Okay, thank you. So the question is Regarding the ability to route queries to read only or or read write master servers How do we know whether the information is up to date with the with a master because replication can be a sink in postgres So the slaves may be delayed regarding to the master. Well, the idea is first of all not to make the driver extremely complicated So the idea is that we provide an API which allows you to do that Whether you want to do that or not it's gonna be at the end of the day your decision There's no clear way in postgres right now to get explicit feedback at the protocol level So we could you know be Listening to the network and see who is up to date or not. So we're gonna ask of today We're gonna live that decision to the user. We're just gonna provide the primitives for you to say hey fire just query and and Bring it up from the first slave available or I want to target a specifically the server more questions I believe so Yeah, yeah the idea right now. So One problem also by using PL Java or any other Sorry, I'm gonna repeat the question first. So did PL Java solve the single thread issue that they had before? So the main problem between Postgres model and Java is that Java is a multi-threaded language So you can create multiple threads within the same process Whereas postgres is a postgres a process based model where you have one process per connection So what happens if you create multiple threads inside a Java program that are working against the connection? As far as I know, I'm not an expert in PL Java though But as far as I know what PL Java does if you remember I mentioned that PL Java wraps the SPI interface The the API that postgres has in C to access the database What they do is to serialize all the calls through the SPI entry point so SPI is wrapped on GNI calls and Those all they all serialized So if you create like many threads in in PL Java that you're supposedly allowed to do that But then if you try to connect to the database from all those threads The connections will be serialized to the database won't break. This is you don't get get any any speed up Okay, so the question is about query pipelining in Postgres Basically query pipelining. It's it's a concept that it has not been developed extensively in postgres. However, however the protocol kind of Permits that to happen So if you look at the Phoebe protocol the postgres protocol, it's it's mostly a completely async protocol Not only you can get replies asynchronously in so many ways, but there are also asynchronous events happening Did you have to be watching over the wire? There's nothing preventing you from sending like several queries at once and waiting for the results to come back It's not an easy task neither because there's There's not like there's a lack of kind of query ID or something like all the protocols of the other databases have So it's a little bit tricky to implement query pipelining Per se because the driver has to cooperate and try to remember the order in which the queries were sent Good things is that the good thing is that the results will come in the same order as you sent them However, as long as it's a little bit tricky because of this No driver before explore this possibility, but we want to explore this possibility because of course I mean if you're running on a transaction mode At some point if you fire a query that that breaks You'll roll back everything and do you'll get errors and so all this handling of errors after you throw some you say you So throw like eight queries on the fifth of while of those fail How do you handle all the errors and recover all that but it's possible So technically it's possible from the protocol level. It's just it hasn't been explored on drivers Part of it is that also the JDBC spec does not support query pipelining per se So it's synchronous API. So you have to get around that But the ability to to summarize is to send five queries in a row and get all the results as soon as they happen Without having to wait for your result to send the next query wait for the results and the next query and so on More questions Okay, so are you dependent on Oracle when using Java? There's a lot of licensing debate about this my personal opinion, I'm not a lawyer but my personal opinion is that Despite being covered by some Oracle own patents Java it's so far completely free operating language and as I've shown it has a really vibrant community I Put in bed on Java failing because of that. So I would be comfortable using Java But if you're not comfortable using Java you for sure can license it from Oracle I mean if you use the Oracle Proprietary version of the JVM and you get a support contract and so on you'll be pretty much safe because you're there providing that So that's an option to but not to avoid using Java just because of that that would be my my recommendation Okay, thank you. Thank you very much