I'm trying to implement two-phase commit using PHP and MySQL, and coming up short.
The main block I've found is that I'm unable to store the MySQL connection resource in a place where I can find it again for the second phase. Is it possible to serialize a database handle?
Here's the case I'm trying to code for:
User sends data
Server starts a MySQL transaction and executes some queries based on the data it has received.
Server sends a file back to the user
When the user has successfully received the file, the server commits its transaction. Otherwise it rolls it back.
This seems to require two HTTP Request/Response cycles, so I need to be able to re-connect to the same database handle in the second request in order to commit the transaction. I've been failing at this part.
Any advice is welcome, even if it's "this is not possible in PHP"
Take a look to LIXA Transaction Manager (http://lixa.sourceforge.net/) it integrates PHP and MySQL starting with release 0.9.0
It provides Distributed Transaction Processing and two phase commit feature as well.
Regards
Ch. F.
Since php is Request / Response based the implementation of a persistent DB connection is not possbile, AFAIK.
You could try to work around this limitation using sort of a ticketing mechanism. Your steps would be:
User sends data
Server starts a MySQL transaction and executes some queries based on the data it has received, assigning a 'unique' ticket to that transaction.
Server sends a file and the ticket back to the user
When the user has successfully received the file and sent another request containing that ticket, the server commits its transaction. Otherwise it rolls it back.
refering to Cassy's comment: after a certain period of time all not commited TAs should be rolled back in order to prevent your db from beeing 'flooded' with old transactions
HTH
to answer KB22 and rojoca, the reason I need to do it this way is that the 'file' i'm referring to is actually a sqlite database that ends up as a data store on a mobile device.
The first request posts the updated sqlite database to the server, which attempts to merge in data from the sqlite tables; problems arise when the mobile device doesn't successfully receive a new sqlite database (one which reflects the mobile device's changes and any other new stuff from the web application), because it will then attempt to send the same (old) sqlite database to the web a second time, resulting in duplicate entries in the web tables for anything which was created on the mobile device.
So, the web needs to be sure that the device has the new database before committing the merge changes. Given the vagaries of networks, this only seems feasible if the device can send an explicit ACK after receiving the new sqlite database. And this is only possible if we make two requests (1. The sqlite database to merge; 2. the ACK of receipt of the new sqlite database on the device).
A thorny problem indeed, and it's useful information to find out that PHP can't manipulate database handles down to the necessary level.
[I also don't think I can use a transaction table because I need to return data to the device based on the 'real' web database tables. I think i'd run into issues with auto_increment fields if I didn't use the real tables]
Thanks for all your comments.
Related
I am implementing a synchronization process between two devices. Web and mobile. I have planned an algorithm but not sure about the possibility of its implementation. My algorithm is,
Mobile will generate a ajax request to PHP script to sync its data onto database.
PHP scripts starts a transaction, then insert data into to database that mobile sent and collects data that it has to send to mobile and send resposce but do not commit.
Mobile receives response, starts a transaction, and send another ajax request as acknowledgement to php script and commit at mobile side.
PHP script receives acknowledgement ajax request and commit its data as well that i developed in setp 2.
My question is, is it possible to use single php thread to work with two synchronous ajax request?
I will leave the php concepts to experts.
We had a similar scenario, where we would send the data to server and insert it with a flag value (e.g., incomplete), then we will acknowledge back to device saying that xyz rows were inserted. It will also contain an unique identifier per device so that we can keep track of which device sent what data, we will also maintain the details of unique identifier per device, unique transaction id (uuid) and timestamp in a separate table (transaction_status). The acknowledgement will be updated in clients, this will basically remove the transactions from the sync queue maintained on the client.
When the next set of records from the same client reaches server, the server will query for the matching entries in the transaction_status table. if the entries are already available, it means that the acknowledgement did not reach the client and server will respond with necessary data in such case.
If the next set of records did not contain the entries which were sent during previous sync then those considered as successful sync and the incomplete flag will be update.
I understand that this might be vague, but i will try to create a diagram in my free time to clearly depict this scenario.
Please leave a comment if you need more clarification.
Anyone having a better approach, please feel free to share.
I finally ended up using websockets. And to implemet websockets in PHP i used Ratchet. I was able to get what i was trying to implement.
I am working on a small client-server project. The front-end is an Android application and the back-end is written in PHP. There is going to be several clients (10+-) that are going to manipulate the data in the server database. Those changes should be immediately reflected to all connected devices.
My question is, should I use sockets so the server will send the updated data to all connected devices once something gets updated or should rather a device be responsible for checking for updates on the server? If so, what would be the best way to do it? Should each row in the database have an update times-tamp and I always fetch all rows whose time-stamp is bigger than the time-stamp of the last update on the device.
I think push notification the best solution for this task. And of course need to have timestamp of last changes in database and android client.
THE ESSENCE
I have a table in my database (SQL Server) and a WCF service that communicates with DB to affect it. I also have a PHP script on my server. Now whenever my table has some data added, modified or deleted I want my PHP script to be executed automatically.
ITS APPLICATION
I am working on a mobile application that is almost completed. Now I need to implement a push notifications feature. I.e. whenever there is a change in the database I have to run my server side script that is configured to push a notification to the user.
Push servicing should be implemented in the layer that adds the data to the database. A database is merely for storing information not for executing code. So in order to create push notifications you would need an interface that receives the updates, sends it to the database and pushes it to the users.
Seeing your question, I certainly don't hope you allow your app to directly add information to the database without some layer that validates incoming information. That's a direct security risk.
A solution of a model would be:
App -> send information -> Website -> analyzes request in PHP/other code languages -> inserts in Database -> push message to clients.
You don't say what RDBMS you are using but whatever one it is, you need to read the documentation about "triggers". This should give you all you need to know.
Most of the time this is done using cron (or another scheduler) to check a database on a certain interval (every minute for example) to find new work and then process it.
However, that sort of design only gets you so far and the next stage would be to move up to using a message queue (Like gearman, ZeroMQ, etc).
You might be able to make something work with triggers, but generally, a database should not be treated as a queue.
I'm trying to figure out the best way possible to notify my web-application of database changes. The way I'm doing it now, is that I've got separate MySQL table with a counter.
Now, when some database action happens in table Foo, a trigger is adding up the counter.
The web-app then polls every 5 seconds the server to check out, if something has happened (counter number has changed) and if so, refresh the data in app.
What I would like, is that I would be able to do callback/notify from MySQL to the server and from there to the web-app so that I don't need to poll the server frequently. Is this possible somehow?
How does facebook, gmail send the real time notification?
You can't notify your application directly from MySQL, but there are some solutions to save bandwith and load of your server.
one way of handling this - would be to either implement the observer pattern yourself or simply use a pubsub messaging option (ZMQ/AMQ/RabbitMQ/Redis etc) - when the initial database action takes place (ensure that the transaction has committed), publish the message to the topic on the pubusb tool - your application can subscribe to the pubsub tool and receive messages when there is a DB change.
Hope it helps.
I'm using Flex 4. Have PHP backend and mysql database with one table consisting of multiple rows.
I take the raw data from the result event and decode it using JSON. I then dump the data into an ArrayCollection that I use as my datagrid's data provider.
My question is how can I tell when someone inserts a new row into the mysql table so that I can automatically refresh my ArrayCollection, thus seamlessly updating my datagrid one element at a time? Right now, it's just a one time call and the connection is closed. If someone inserts a new row into the database my program doesn't recognize, unless I restart it. I'd like to auto-update the AC whenever a single new row is inserted into the mysql database. Is there a way I can "listen" for this change?
Ah, you've stumbled upon the age old question of the web realm: Polling or Pushing?
Polling means that you ping the server every few seconds or minutes to check if there's any data that has changed. If there is, your server sends you the new changed data which up update appropriately on your front-end. The 'protocol' on how to interpret which piece of data needs to be updated is totally up to you since there's no real standard (since data in itself can be very different from system to system). Polling is still in use today in many systems that do not need crucial 'live' information and since it doesn't need a consistent connection, it's particularly good for iffy internet like mobile. Plus, everything is an HTTP request, so there's no enterprise firewall that can block it.
Pushing means that you have a constant connection between your front end and back end which normally goes over RTMPT (HTTP UDP protocol to circumvent enterprise firewalls, but not 100%). It's great if you need real time data (like say financial data) to be delivered to you quickly. However, the user needs a consistent internet connection and you need to have a server capable of dealing with the amount of connections and sessions management. Normally, most people end up using Java since there are many libraries to handle pushing (BlazeDS, GRaniteDS, Livecycle, Wowza, etc).
Since you're using PHP, you'll probably need to use polling as your solution, but need to implement it yourself. I'm sure there are libraries out there to help you out though.
No, there is no automatic way to do that. But you can regularly 'ping' your server and ask for new rows. Use
setInterval(myFunctionName, timeToWaitBetweenEachCallInMilliseconds);
to do that.