I have a method with transaction annotation that persist an entity and then do a call to an oracle function who read this non persistent data but the function never see the data inserted in the first step. I'm doing this because is function fail then a rollback must be done. Another thing is that the function update a different database.
Any help about how to do this?
Related
I have a oracle view it returns 5 million records from different tables and i use this view to insert into different tables using a single procedure, inside this procedure i use this several times and this is affecting the performance, is there any way we can query the view once and later i can use it multiple places?
A view is a stored query; itself, it doesn't contain any data. If its code is complex and fetches data from several tables, using different conditions, aggregations, whatnot, it can take some time to access data.
In your situation, maybe a global (or private; depending on Oracle version you use) temporary table (GTT) would help.
you create it once
at the beginning of the procedure, insert data from the view into it
the rest of the procedure would work with those prepared data
once the session (or transaction; depending on how you set the GTT up) is over, data from the table is lost
the table can be reused next time you run the procedure
I've a job which runs with multiple instances i.e. the code base for all instances is same, but each instance works on set of data allocated to it so as to achieve parallelism and better throughput for the application.
These jobs use global temporary table for working through the data as there are multiple complex operations performed before final output is computed.
In case of failure, the transaction is rolled back (as it should), but with this I'm also losing the data in gtt.
Is there a way that the records in gtt can be copied over to another permanent table while rolling back the transaction.
I know it sounds weird, but this is a practical problem I'm facing.
I need to somehow store data in session table in case of failure of any sql, while rolling back the transaction as one of the sql has failed.
Thanks.
Hm, maybe something like this:
create a permanent table which will hold GTT data in case of failure
create an autonomous transaction procedure which would insert into permanent select * from gtt and commit
in exception handler section call that procedure and then rollback
The only way is printing the required data before your rollback.
You can use UTL_FILE to store data in the file. Later, you can use external table concept of oracle to retrieve data in the table.
Cheers!!
I have a lambda function which I am using to create the DynamoDB table.
I have a requirement, wherein I need to insert some data in this table, after the table is created.
In DynamoDB, Create table is an asynchronous call. While the table is being created, it is in "CREATING" state and after that it goes into "ACTIVE" state.
The challenge is, I can't insert the data in this table, till it is not in "ACTIVE" state and I get ResourceNotFoundException exception.
Is there any way, I can insert this data in the table while it is created?
I want to complete the table creation and the data insertion in the same Lambda function call.
As you've discovered, you can only write to an active(/created) table, and there is no way to provide data for 'preloading' your table using dynamodb::CreateTable.
There are no events emitted for when the table is ready. So instead you'll have to poll until the table becomes active. This should be easily achieved in a lambda, as DynamoDB rarely takes more than 30-60 seconds to provision a table.
After creating the table, you can call dynamodb::DescribeTable every second (or so) and wait until it returns Table.TableStatus === 'ACTIVE'. Once they table status has turned to active, you can insert your initial data. Just remember to increase your Lambda timeout to the full 15 minutes, in case it does take AWS longer to provision your table.
You can see an example of this in the AWS Documentation.
Like in procedures and Functions can we pass parameters to triggers? Can A trigger can be explicitly called?
An object based trigger is raised by an event's occurence(as update,insert,select)on a specific object of the database. There is also system triggers, fired by system specific events(as shutdown,startup database, user connection etc..).
This is the main purpose of a trigger in databases, you can't raise it explicitly, if you want it to run the only way is to raise the event. Also passing parameters isn't part of trigger definition, but you can handle the event attributes,(which can be passed to the trigger body that may can contain functions or procedures).
I hope that i've responded to your question, can i know what is your need for trying to do that.?
What you can do is to create a table that will store temporarily the data that you want to access in your trigger.
1-Create a table "tmp_data" for instance.
2-Before running the event that will fire the trigger (stored procedure, insert, update...) insert into tmp_data the data that you want to use in the trigger.
3-In the trigger, to access the data you needed, you make a query on the table tmp_data.
4-After have been done with the data, you clean the table tmp_data for the next use.
Hope has been helpful!
Using Oracle 10g
Is it possible to get the value of a newly updated field within the same transaction before it is committed.
I am executing a stored procedure which calls 2 other stored procedures.
The first stored procedure gets a record from a table and then updates that record.
The second stored procedure gets that same record but needs to use the newly updated fields from the first stored procedure.
Then the commit is carried out.
The commit can only be done if both procedures are carried out sucessfully.
Will the second stored procedure get the newly updated data or will it get a copy of the same data that was returned in the first procedure without the update ?
Oracle has a very simple and robust implementation of read consistency:
a user sees the latest version of the data, including any changes made by the current transaction, but ...
a user cannot see the changes made by any other user until that other user issues a commit, and even then not until executing a new statement.
This is covered in the Concepts Guide. Find out more.