Skip to main content

Domain Mode Aware Teiid

Teiid 8.0.0.Beta2 is released today with  "domain mode" support provided by JBoss AS 7. This release is based on JBoss AS 7.1.1

So, what does "domain mode" provide to Teiid?

When you have more than one JBoss AS instance in your server farm and if they are started in domain mode, all the configuration options of this server farm can be centrally managed. For example, you can deploy a VDB or create a data source across all the instances, with one single CLI based call.  Teiid extends this configuration concept to deploy the VDBs, Translators across the whole server farm.

Also, when domain mode is combined with "HA (high availability)" profile, one can cluster the JBoss AS server instances that are deployed. Teiid chooses the HA profile as default profile in its "domain-teiid.xml" file. When the Server is started using the "domain-teiid.xml" the distributed caching that is used for ResultSet caching and Internal Materialized caching is automatically configured. The usage of Admin API is same in both standalone mode and domain mode. See the following document to start in Domain Mode with cluster capabilities.

When multiple Teiid instances are available in a cluster, you can make use load balancing and fail-over features. Check out Teiid documents.

Other Stuff

We are fast approaching CR1 release in next couple weeks, then soon followed by  8.0.0-Final, so check your use cases and let us know if you see any issues before it is too late to get them into 8.0.0-Final.

We are also planning the 8.1 work currently, so if you have any feature(s) you think that Teiid should implement speak up and open a dialogue in Teiid forums.

We are looking for GWT experts to help us with Teiid Console application in 8.1, so if you got some time to spare and want to contribute back to Teiid, please contact us.

Download and try it out and let us know if you see any issues or question in Teiid forums.

Thank you.



Popular posts from this blog

Teiid Runtimes Explained

If you have been following Teiid lately we have been going through a whole lot of renovations. Yes, renovations or reorganization or refactoring or whatever you want to call it. Basically, we are making Teiid more modular with fewer dependencies that can be used by however your use case dictates rather than use it as one monolith application deployed into WildFly JEE Application Server. There is nothing wrong in using Teiid as server model, but with the proliferation of container-based workloads and cloud-based architectures, the previous server-based model does not work or simply won't scale. So, we needed to think of alternatives, thus Teiid team introduced a couple different versions modular Teiid what we are calling as "Teiid Runtimes".

Note that in these modular Teiid runtimes, not all the features you were used to using in Teiid Server model may not be there but you will have extensions to add in those that are most appropriate for your domain. If you are looking …

Teiid Platform Sizing Guidelines and Limitations

Users/customers always ask us about the sizing of their Data Virtaulization infrastructure based on Teiid or the JDV product from Redhat. Typically this is very involved question and not a very easy one answer in plain terms. This is due to fact that it involves taking into consideration questions like:
What kind of sources that user is working with? Relational, file, CRM, NoSQL etc.How many sources they are trying to integrate? 10, 20, 100?What are the volumes of data they are working with? 10K, 100K, 1M+?What are the query latency times from the sources? How you are using Teiid to implement the data integration/virtualization solution. What kind of queries that user is executing? Even small federated results may take a lot of server side processing - especially if the plan needs tweaking.Is materializing being used?Is query written in optimal way?and so on..Each and every one of the question affects the performance profoundly, and if you got mixture of those then it become that much…